Linux Proxy doesn't see vSAN datastore for hot add

[infraerik]

A curious one I just ran across on a client site. They are currently moving off an older cluster to a new vSAN (vxRail) cluster and using Replication to prepare the migration. I was noticing some pretty awful performance as there are some networking issues to work out, but I also noticed that that destination proxy (Debian 10) was always switching to NBD mode and forcing the traffic through the router to get to the ESXi management interfaces instead of using the dedicated backup VLAN. When I forced it into Virtual Appliance mode, it continued using NBD, even with that option explicitly disabled.

So I noticed that I could manually choose the datastores it should/can connect to, but in that list, it only shows the local VMFS datastores of the spare space on the ESXi boot drives of the vSAN cluster. the vSAN datastore is not visible. However it is/was visible when creating the replication job and was selected as the destination and replicas are being created and updated correctly (albeit slowly).

Baffled.

[david.domask]

Heya @infraerik,

When you talk about selecting volumes, you mean step 5 here, correct? https://helpcenter.veeam.com/docs/backu ... ml?ver=110

That's just for DirectSAN and DirectNFS connections, it won't influence hotadd.

For your issue, just to confirm, the proxy itself has all its disks on the same vSAN, correct?

https://helpcenter.veeam.com/docs/backu ... ml?ver=110

If this is indeed the case, it bears raising a support case just so we can confirm why the proxy was not eligible for hotadd transport mode.

Be sure to include logs as per https://veeam.com/kb1832 and use the 1st option and select one of the jobs where you saw this behavior; it should be enough to start with (though depending on the situation, more information might be needed)

[NightBird]

Are your proxy on the vsan datastore ? If not it doesn’t work and use nbd mode.