Yesterday, I was working with Veeam Availability Orchestrator .next beta, and ran into a fun issue. During a Recovery plan test, the VMs are brought into vSphere using Veeam’s Instant VM Recovery. If you’re not familiar with IVR, Veeam is able to mount the deduped, compressed backup, and present to vSphere via an NFS mount, and then adding the VM into inventory – all running from the backup, not production storage.
However, in my case, this NFS mount didn’t happen. I verified that my other Veeam servers had no issue, and then attempted to manually mount the vPower NFS volume from my ESXi server. See details here:
I went through the normal troubleshooting – making sure the service was running, and that everything was pingable.
I then dug into my Veeam logs, and found this error:
Unable to get console path for volume
At this point I SSH’d into my host, and attempted to mount from cli using the following command:
esxcfg-nas -a -o 192.168.1.127 -s /VeeamBackup_vao-beta.tsmith.local VeeamBackup_vao-beta.tsmith.local
Just like in the GUI, it failed, but this time with a helpful message!
Error performing operation: Unable to add new NAS, volume with label VeeamBackup_vao-beta.tsmith.local already exists
This was very interesting, as I didn’t have a datastore with that name mounted! again, using the cli I verified that no nas volume was mounted with that name.
As you can see, only my 2 Synology datastores and 1 VAO (non-beta) datastores are mounted, not the datastore from my beta server. For kicks, I entered the command to remove the non-existent datastore.
esxcfg-nas -d VeeamBackup_vao-beta.tsmith.local
What do you know! The datastore was deleted, even though ESXi told me it didn’t exist!
At this point, I went back into VAO, and ran a lab test, allowing it to mount the vPower NFS volume automatically and everything worked perfectly! So, if you have an NFS volume that won’t mount, and you’ve verified that it doesn’t exist, it may still in fact exist, and need to be manually deleted before you can mount it again.