Questions About ESXi to XCP-ng Migration Methods (VDDK vs Non-VDDK)

[mdm]

Hello,

I have a few questions regarding the ESXi → XCP-ng migration process and how Xen Orchestra handles it internally.

1. When VDDK is available and configured, how does the migration process work exactly?
2. Is the data transfer happening directly between the ESXi host and the XCP-ng host, or is the traffic proxied through Xen Orchestra as well?
3. I understand that migration can also work without VDDK. In that case, what method is used internally?
4. If VDDK is installed/configured in Xen Orchestra, is it possible to manually choose which migration method to use? I’m asking mainly for testing and benchmarking purposes. Or does XO automatically decide which method will be used?

Thanks in advance for any clarification.

[julienXOvates]

Hi @mdm,

Here is the response from a SME
1-

• XO get the VM metadata through soap api and create the vm /network
• XO use the nbdkit + nbdkit-vddk package , connecting to each disk
• XO connect through NBD to nbdkit
• XO list the allocated blocks
• XO create the disk
• XO read the block and import the data into the disk (though a vhd or qcow2 stream depending on the size)

2- though XO. There is a lot of disk transform occuring here

3- not anymore, it was too brittle, especially on when the disk are locked or not. Also it was not scaling too well
4- see 3- +
vddk transfer is overwhelmly faster that previous access through http, is compatible with VSAN and don't lock the disks.

(+ also see https://xen-orchestra.com/blog/xen-orchestra-5-110/ section "VMware to Vates (V2V)" where we made key improvements)

[olivierlambert]

Question for @julienxovates

[julienXOvates]

Hi @mdm,

Here is the response from a SME
1-

• XO get the VM metadata through soap api and create the vm /network
• XO use the nbdkit + nbdkit-vddk package , connecting to each disk
• XO connect through NBD to nbdkit
• XO list the allocated blocks
• XO create the disk
• XO read the block and import the data into the disk (though a vhd or qcow2 stream depending on the size)

2- though XO. There is a lot of disk transform occuring here

3- not anymore, it was too brittle, especially on when the disk are locked or not. Also it was not scaling too well
4- see 3- +
vddk transfer is overwhelmly faster that previous access through http, is compatible with VSAN and don't lock the disks.

(+ also see https://xen-orchestra.com/blog/xen-orchestra-5-110/ section "VMware to Vates (V2V)" where we made key improvements)

[mdm]

@julienXOvates Thanks for the quick reply, that’s very helpful!