Does EnableSameHostHotaddMode only apply to VMs on NFS?

[loelly]

So, I'm running Veeam B&R 8.0.0.2030 and my question in basically written in the subject line.

I have a couple of proxies (each pinned to a host) and I notice that VMs on VMFS5 get hot-added by random proxy server, whereas VMs on NFS get hot-added by proxies on the same host - as expected when setting EnableSameHostHotaddMode. So, is it expected behavior that VMs NOT residing on a NFS mount get backed up by any proxy within the cluster?

Thanks,

loelly.

[veremin]

So, is it expected behavior that VMs NOT residing on a NFS mount get backed up by any proxy within the cluster?

No, it's not, as the said key should work regardless of type of shared datastore.

It stands to reason to open a ticket with our support team.

Thanks.

[dellock6]

Uhm, this is interesting indeed so please keep the thread updated. I'm testing the key myself on a Nutanix block (so NFS) and the key with value=2 is indeed keeping hotadd local.

Out of curiosity Maik, what storage solution are you using? When there is no data locality as in Nutanix or other hyperconverged solutions, since the datastore is shared among ESXi, they all have the same network paths to access the storage, so the regkey is not gaining any advantage. And I'm not aware of hyperconverged solutions having data locality and block volumes at the same time.

Luca

[loelly]

Hey Luca,

Uhm, this is interesting indeed so please keep the thread updated. I'm testing the key myself on a Nutanix block (so NFS) and the key with value=2 is indeed keeping hotadd local.

Out of curiosity Maik, what storage solution are you using? When there is no data locality as in Nutanix or other hyperconverged solutions, since the datastore is shared among ESXi, they all have the same network paths to access the storage, so the regkey is not gaining any advantage. And I'm not aware of hyperconverged solutions having data locality and block volumes at the same time.

Luca

I need the key mainly for VMs residing on NetApp (and Tintri, currently doing a PoC). The reason to use this for is the huge outage (20-30 seconds) when using HotAdd and attaching the disk to a backup proxy located on a different ESXi host. This is unacceptable to us, as we're running 24x7 and critical production data is stored on file servers residing on NFS. I just noticed that only VMs actually residing on NFS got hot-added locally and others get different proxies (which is a good thing, I don't need block-stored VMs attached locally).

VMware has a KB here documenting the issue: http://kb.vmware.com/kb/2010953

vSphere 6 is not listed on the "Applies To" section, so the issue might have been fixed there.

I've set the key to value 1. Did not know there are other options. What does a value of 2 do?

[veremin]

The difference is:

1 - In this case, when proxy A is available on the same host, we will leverage it. If it's busy, we will wait for its availability. But if it becomes unreachable for some reason, we will use other Hot-Add proxy B.

2 - In this case, when proxy A is available on the same host, we will leverage it. If it's busy, we will wait for its availability. If it becomes unreachable for some reason, we won't use other Hot-Add proxy B. Instead, we will switch to NBD mode.

Thanks.

[loelly]

Hey Vladimir,

thanks for the clarification. Good to know!

Regards,

Maik.

[veremin]

You're welcome, Maik. Feel free to ask, if additional clarification is needed. Thanks.

[dellock6]

Yep, Maik you should use value 2 for optimal results.
So you know, I'm finishing the tests on the Nutanix block, and the results so far using option 2 is promising: VMs are processed locally in hotadd and remotely with network mode, and I've seen no stun at all. The cluster is vSphere 5.5 + NFS v3. I have no information if the issue has been solved on vSphere 6 or (as I suspected) the KB is simply not yet updated for v6, as maybe few people have faced the same issue yet. Anyway, I think when using hotadd this can be a good solution anyway even if the stun issue is solved.
With Veeam v9 you will have the new option to run DirectNFS, but for now this key is a good solution in my opinion.