Snapshot removal stun on NFS

[jhoppe82]

Hi fellow Veeam users. I'm currently dealing with an issue regarding snapshot removal stun when removing snaps from VMs running on a NFS Datastore (NetApp). I tried implementing the fix in http://www.veeam.com/kb1681, but my jobs are still selecting any proxy that can hotadd regardless of location. My proxies are all pinned one to each host.

I'm running Veeam v7 build 7.0.0.871. We haven't upgraded to 8 yet because I am trying to sell management on the license upgrade to enterprise plus for the NetApp Storage integration. They are a bit hesitant to give Veeam more money when we have an outstanding issue with them, even though it would resolve the issue and provide many other benefits.

Has anyone seen any cases that would cause the registry key in the KB to not work? I have redeployed my proxies, and I made sure all my jobs are set to automatic selection. We only have a few servers being affected by the stun, but they are highly visible servers to management and the public.

I already have a support case open with Veeam (#00737309), but wanted to see if anyone else has ran across this.

[foggy]

Justin, you seem to be the first to report the key is not working. I would double-check it is correctly deployed (there're no spaces in the value name and it is added under the correct key). If everything looks perfect and proxies from remote hosts are still selected, then please continue investigating with technical support. As a workaround, you can edit the jobs to configure particular local proxies you want to be selected (instead of using automatic selection), unless VMs are moved between the hosts regularly.

[cvacanti]

I can tell you from my testing that with Veeam 8 storage integration with NetApp I've seen VM stun times go from over 13 seconds down to 1-2 seconds in a high i/o sql environment. All this improved because of NFS storage integration on the NetApp.
Chris

[dellock6]

Thanks Chris for the feedback, indeed if possible upgrading to v8 and enabling direct NFS connections from Veeam (physical maybe) proxies to NetApp NFS shares will remove completely the NFS stun issues.
Anyway, Justin we are checking internally about some enhancements to the registry key for future versions to force local proxy usage without failover to remote proxies. As Alexander said, one workaround for now is to lock a backup job to a specified and local proxy avoiding automatic selection, at least for those sensible VMs.

[jhoppe82]

Justin, you seem to be the first to report the key is not working. I would double-check it is correctly deployed (there're no spaces in the value name and it is added under the correct key). If everything looks perfect and proxies from remote hosts are still selected, then please continue investigating with technical support. As a workaround, you can edit the jobs to configure particular local proxies you want to be selected (instead of using automatic selection), unless VMs are moved between the hosts regularly.

We use DRS and movement is fairly common, so I would prefer to not break out jobs by host. Not all of our VMs are backed up either, so I can't just select at the host level.

I can tell you from my testing that with Veeam 8 storage integration with NetApp I've seen VM stun times go from over 13 seconds down to 1-2 seconds in a high i/o sql environment. All this improved because of NFS storage integration on the NetApp.
Chris

I haven't been able to sell management on the benefits of upgrading our license to Enterprise Plus for the NetApp integration. Believe me, I wish I could. How are the NFS improvements without storage integration?

Thanks Chris for the feedback, indeed if possible upgrading to v8 and enabling direct NFS connections from Veeam (physical maybe) proxies to NetApp NFS shares will remove completely the NFS stun issues.
Anyway, Justin we are checking internally about some enhancements to the registry key for future versions to force local proxy usage without failover to remote proxies. As Alexander said, one workaround for now is to lock a backup job to a specified and local proxy avoiding automatic selection, at least for those sensible VMs.

Is there a way to get direct NFS connections from virtual Veeam Proxies in v8, short of storage integration with E+? Adding more physical proxies is against our general strategy of virtualizing everything I can. I'm working on the Veeam v8 upgrade once I get through some management red tape.

Although it is a ways off before we will move to it, it seems like vSphere/ESXi 6 will improve this as well, now that VMWare is going to support NFS 4.1

[dellock6]

Justin, if you create virtual proxies with ethernet connections in the same subnet as the nfs storage and you force them to use directsan, indeed they will work as physical proxies (this can be done on any ethernet storage).

for NFS 4.1, we need first to check if file locks is one of the improvements compared to v3. Not that I'm not hoping for it, but better be sure before toasting at v6 (in regards to this topic, in general it has tons of cool features indeed!), even if "In-band, mandatory, and stateful server side locking" sounds promising

[jhoppe82]

Justin, if you create virtual proxies with ethernet connections in the same subnet as the nfs storage and you force them to use directsan, indeed they will work as physical proxies (this can be done on any ethernet storage).

Interesting. I've always seen that NFS and directSAN don't work together. I can give this a shot.

[dellock6]

They do on v8 when you leverage NetApp integration.