Problem importing ANY ESXi VMDK into Xen Orchestra CE
-
@Danp
In VMware->
In XOA after import ->
-
I haven't heard of this before. Maybe @florent will know why this is occurring.
-
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.
No idea if there's a way to avoid that.
-
@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
-
@florent I did import my VMs with V2V, it was not with a vdmk import.
-
@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 ?
-
@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 } ] }
-
@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?)
-
@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
-
@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.
-
@florent
Hi Florent,The imported VM was definitely not in DHCP mode, it was a static address.
I have an XOA and XO from source, but we already re-purposed our VMware server, so sadly I can't help you debugging anymore.
Maybe you can do that with the original poster of this thread? -
@Mathieu said in Problem importing ANY ESXi VMDK into Xen Orchestra CE:
@florent
Hi Florent,The imported VM was definitely not in DHCP mode, it was a static address.
I have an XOA and XO from source, but we already re-purposed our VMware server, so sadly I can't help you debugging anymore.
Maybe you can do that with the original poster of this thread?This was probably a mishandled response in the SOAP api, it is not logged. We 'll try to reproduce in our lab.
But at least a decomissionned esxi is a good news -
@Mathieu said in Problem importing ANY ESXi VMDK into Xen Orchestra CE:
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.
No idea if there's a way to avoid that.
Yeah same, we're also using VMXNET.
When trying to do this manually there's a popup which you have to accept to "force" having the same IP on multiple interfaces. Im sure the IP's are save in registry so deleting the post as part of the process would probably resolve it.