VPower NFS volume already exists

[jsramrod]

I've opened a case with support but am not getting a response so thought I'd see if anyone can help here. Running v5.0, doing a surebackup of exchange vm. All has been working fine for months and a couple of days ago, the job hung and had to be cancelled. Now, when the job runs, I get this error:

Details
3/2/2012 4:00:25 AM Getting virtual lab configuration
3/2/2012 4:01:20 AM Starting virtual lab routing engine
3/2/2012 4:01:21 AM Fail server: Publishing
Unable to mount vPower NFS volume (VCENTER:/VeeamBackup_VCENTER). vCenter.domain.local: The name 'VeeamBackup_VCENTER' already exists.
192.168.1.48: The name 'VeeamBackup_VCENTER' already exists.

I'm assuming something didn't get cleaned up due to the hang but not sure what I need to clear in order to get it to run again. Any help is much appreciated.

[Gostev]

Please be sure to include support case ID when posting about any technical issues. Thanks!

[Cokovic]

Sounds like the NFS share from your Veeam server is still mounted on your ESX host. Klick on the corresponding host then go to "Configuration" and take a look under "Storage". Is there a NFS share mounted called "VeeamBackup_VCENTER" ?

I've seen this in the past in our environment too. But never had any problems with it. It also wasn't a problem to unmount this NFS share manually if it wasn't used by any job running.

[jsramrod]

Haris,

Thanks for your quick reply! I did see a NFS share mounted called VeeamBackup_VCENTER(1) which I dismounted. Kicked off the exchange job after that and almost immediately got the below vSphere alert. Not sure how to insert an image, but the NFS volume is now showing again, with an alert status obviously, and shows 5 GB of free disk space. Not sure if that's not enough or what's going on.

Thanks again for your reply. Ticket number is 5176239 and it looks like I just got a response on it.

Target: VeeamBackup_VCENTER
Previous Status: Gray
New Status: Red
Alarm Definition:
([Yellow metric Is above 50%; Red metric Is above 75%])
Current values for metric/state:
Metric Space actually used = 83%

[Cokovic]

Can you run your exchange surebackup job without any issue now?

Just use another location with more free disk space for the vPower NFS service on your Veeam server.

[jsramrod]

It did finish successfully! Thanks again. It looks like the NFS volume stayed mounted though which I guess will cause a problem the next time the job runs. This is going to be a dumb question, but how change I change where the NFS volume mounts, to give it a location with more space?

[foggy]

It's in the repository wizard, at the vPower NFS step.

[Cokovic]

There are no stupid questions only stupid answers

Great that it's working again. You are welcome.

[jsramrod]

Can't seem to locate the repository wizard, but saw another post by Gostev that indicates a registry key that can be changed. I changed NFSDefaultRootPath key to a different drive, restarted the vpower service and ran the job again but it still used the old location. Is that not the right key? Or, how do I run the wizard?

Thanks again for everyone's help.

[foggy]

I guess this key is responsible for the vPower NFS located on the default repository whether most likely you are using another one. To run the wizard, just open the Backup Repositories node in the console, right-click the repository, and select Properties.

[Cokovic]

Just take a look in your repository, right klick the corresponding one and choose Properties. Klick a few times Next to get to the NFS settings and change the location.

Edit: foggy was faster

[jsramrod]

I'm afraid I'm an idiot, I can't find the repository node that everyone is talking about. I'm running version 5 if that makes a difference. I don't know how to attach an image, but what I see in the Veeam B and R console in the left pane is:

Backup and Replication
Restore
SureBackup
Servers

Under the servers, I see My Computer and the vcenter server. Expand the vcenter server and there's datastores and the IPs of the two vmware servers. Keep expanding things and I do see the veeambackup_vcenter listed under datastores and the one IP, but nothing is right clickable with "Properties" available(greyed out).

I apologize, this is something simple I'm missing for sure, but I don't see what you're talking about.

[Gostev]

Everybody are talking about v6 above, no such thing in v5.

[Cokovic]

Oooops sorry missed the fact that you run v5. Then you're right and the registry is the way to go.

[jsramrod]

Unfortunately, I modified the registry mentioned in my earlier post, restarted the service, but it didn't make a difference.

[Gostev]

As per the value name, NFSDefaultRootPath is the *default* path, so it only applies to the newly created vPower NFS shares, but does not apply to the existing ones. For existing shares, some other registry value is used... I don't remember their location already (v5 is so last century for me), but I remember that they are pretty deep and hard to find.

[Cokovic]

Did you try the keys from this post here?
Changing vPower NFS Datastore

You've got to change the localFolderPath too as stated by Gostev in this topic.

There is also a script someone wrote for that. but never tried it myself. So it's without any guarantee

http://vpowercli.net/2011/10/21/changin ... nfs-paths/

[Gostev]

Here you go, this forum has all the answers you need, just use search

[VladV]

For the sake of consolidation and ease of finding quick solutions I will post my experience with this issue here.

I also encountered this problem when I was running a Surebackup Job after restarting the whole vSphere infrastructure (vCenter and Esxi v5.5).

Following the guide here http://www.veeam.com/kb1690 I tried finding the inactive datastore on the standalone ESXi but with no luck. Even refreshing or re-scanning hasn't made the Datastore appear. The mentioned KB article makes reference to restarting the management services if you fail in unmounting the NFS Datastore, but it my case, this procedure has made the standalone ESXi regain its consciousness and the datastore appeared as inactive. Then I could unmount it and run the Surebackup JOB.

So, adding to the KB article, the restarting of management services on the affected ESXi not only enables you to unmount a stubborn datastore but can also make it re-appear.

Cheers.