Problem importing ANY ESXi VMDK into Xen Orchestra CE

Murf

@Danp updated to Xen Orchestra, commit f7223 and still the same issue.

I have inspected the UI console, in case this helps

Danp

@Murf I'm testing locally with the Windows 2022 VMDK from MS. If I can't replicate here, then I'd assume it is a compatibility issue with the file generated b vCenter.

Danp

So, no issues on my end importing the VMDK into XOA or XO from sources.

@Murf Can you generate a new VMDK without any confidential data using the same technique?

Murf

@Danp Sure, how do I attach a zip file to the post? it wont let me.

Danp

@Murf Sent you a link via PM

Murf

@Danp When I migrate Windows Server VMs the network interface does not have the settings anymore and I have to reconfigure them manually, is this expected behavior?

Danp

@Murf No, that doesn't sound normal. Are you still referring to the import from VMWare process or are you actually migrating between XCP-ng hosts?

Murf

@Danp Yes the import process. I think it is because we are using VMXNET 3 interfaces, not E1000 (which caused us horrible problems over the years)

Danp

@Murf Can you show screenshots of network settings from before and after import occurs?

Murf

@Danp no need really, they are just set to DHCP instead of the static settings we had, as if I had added a new interface altogether

Murf

@Danp
In VMware->

In XOA after import ->

Danp

I haven't heard of this before. Maybe @florent will know why this is occurring.

Mathieu

Just experienced the same issue with a few VMs I imported from VMware.

I think it's a Windows issue, from what I can tell.

The network adapter type changes after the import in xcp-ng (from VMXNet to XenServer PV), that's normal.

Windows do not allow the same IP address to be used automatically for a different type of network adapter, so that's why it reverts to DHCP with the new adapter.

You can see that by setting the previous static IP address in the new adapter, it will warn you that the address was used with a previous adapter and asks for confirmation.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/error-message-when-you-set-ip-address

No idea if there's a way to avoid that.

florent

@Mathieu Hi ,

does it do the same when using the v2v tool ?

the vmdk import does not modify anything , only trasnform the disk format from vmdk to vhd, while the v2v also reconfigure the VM

Mathieu

@florent I did import my VMs with V2V, it was not with a vdmk import.

florent

@Mathieu can you check in the import task log, you should have a part containing the network information extracted from vsphere :

What does it contains ?

Mathieu

@florent This is what I see for the last VM I imported:

  "networks": [
              {
                "label": "VM Network 2",
                "macAddress": "00:0c:29:48:70:d6",
                "isGenerated": true
              }
            ]
          }

Murf

@florent the thing is I am looking for a seamless migration workflow from VMware.. not a manual VM per VM migration. (unless v2v has this also?)

florent

@Mathieu said in Problem importing ANY ESXi VMDK into Xen Orchestra CE:

@florent This is what I see for the last VM I imported:

  "networks": [
              {
                "label": "VM Network 2",
                "macAddress": "00:0c:29:48:70:d6",
                "isGenerated": true
              }
            ]
          }

the VMWare api answer tell us that it's a DHCP network. Do you have a XOA I can patch , or would you be able to test a custom branch of XO from source ? I would like to add some debug here

florent

@Murf said in Problem importing ANY ESXi VMDK into Xen Orchestra CE:

@florent the thing is I am looking for a seamless migration workflow from VMware.. not a manual VM per VM migration. (unless v2v has this also?)

For now, we put most the effort on migrating the data, and do our best for the metadata. There will probably be some manual work, for example installing /removing the drivers, but also the network configuration.

v2v most important advantage is that it does not need to copy the export ( that can be in the terabyte size range) on a disk and then import it. It can also script an import of a huge list of VMs, and handle them with a controlled concurrency, to ensure the esxi doesn't suffer too much.