Hello,
I observe significant differences in transfer speed of Storage vMotion tasks, depending on whether the virtual machine (whose disks are to transfer) is powered-off or powered-off.
When the VM is powered-on, the transfer speed reaches 400 MB/s.
When the VM is powered-off, the transfer speed barely reaches 165 MB/s, that is 1.3 Gb/s, which is the exact limit of what NFC can provide, as stated here [1].
Here below are the tests I performed and the time taken to transfer 16 GB from one datastore to another (all ESXi in the cluster can see the source and the destination datastores and VAAI XCOPY is being used).
- VM powered-off, vMotion/SvM task is "Change storage only". Transfer time: 2'37"
- VM powered-off, vMotion/SvM task is "Change both compute resource and storage". Transfer time: 2'15"
- VM powered-on, vMotion/SvM task is "Change storage only" Transfer time: 59"
- VM powered-on, vMotion/SvM task is "Change both compute resource and storage" Transfer time: 1'08"
What I would like to know is if UDT came into play here or not and whether or not it should have.
VMware support says that UDT only comes into play when the vMotion/SvM task is of type "Change both compute resource and storage" and both ESXi don't see each other datastores (source and destination). I find it hard to believe.
My cluster is a vSphere 8 cluster with 'vMotion' and 'Provisioning' services enabled a vmkernel port group working on the 'Default' TCP/IP stack, so UDT requirements should be met.
Can someone please:
- enlighten me on how and when UDT intervenes?
- tell me if UDT brings an improvement for the turned off VMs that do not change host (Change storage only).
- tell me how to check from the logs that UDT is involved
- help me understand why the cold transfer speed is still lower than the hot one.
Best regards,
Frédéric.
[1] https://core.vmware.com/resource/vsphere-vmotion-unified-data-transport