Problems doing live/warm migrations from vSphere/ESXi 7 to XCP-ng
-
As time is running out to find an alternative to VMware vSphere, I've spent the last couple of weeks trying out various hypervisors, hoping to find one that works and that I myself like.
I finally decided to give XCP-ng and XOA a try, but there is one major issue that currently keeps me from switching over - live/warm migrations to vSphere/ESXi 7.I have eagerly read all announcements and release notes, and was really hoping for a solution when Xen Orchestra 5.93 was released (announcing a work around using NFS).
So, setting up a NFS datastore, mounted in ESXi as <datastorename> and in XCP-ng as [VMWARE]<datastorename> I went forward with migrating VMs to the NFS datastore in VMware and started my attempt to migrate VMs - but no success.
The process immediately shuts down the VM on the VMware side and then starts migrating disks (at very slow speeds, mind you, I have 2 x 25Gbps from hosts to storage).
The slowness I could live with, but I cannot have the extended down time this requires, so I'm desperately looking for some assistance to get this working.The environment currently consists of:
VMware: vSphere 7 Enterprise Plus (vCenter and ESXi running on the currently latest patches)
XCP-ng: 8.2.1 with XOA 5.93 (Premium trial)Migration steps performed:
- Import from VMware (connection to vCenter) with VMFS6 storage to NFS storage (fails).
- Import from VMware (connection to vCenter) with NFS storage to NFS storage (fails).
- Import from VMware (connection to vCenter) with VMFS5 storage to NFS storage (fails).
- Import from VMware (connection to ESXi) with VMFS6 storage to NFS storage (fails).
- Import from VMware (connection to ESXi) with NFS storage to NFS storage (fails).
- Import from VMware (connection to ESXi) with VMFS5 storage to NFS storage (fails).
In all attempts, no live/warm migration is even being tried, the source VM is immediately shut down and an offline migration starts.
One thing I noticed is that the XOA CPU usage maxes out while a migration is in process (default deployment with 2 vCPU's).
Could increasing the XOA resources help out? If so, how can this be done?
When I try to increase the number of vCPU's/RAM of the XOA, it immediately shuts down (does not reboot) and then reverts to the default number of vCPU's and RAM.Is there anything else I have missed?
I'm at a complete loss at how to get this working...
Any help and insights to get this working for me would be greatly appreciated! -
@Carello Hi, I am working on the migration tool
If you have a XOA, could you open a support ticket and then a support tunnel ? We'll be able to connect and see the logs directly, because most of the test you've done should have work.
- a 5.93.1 version has been released with a few fixes regarding the nfs import
- to do a warm migration, the VM must have at least one snapshot . More than one snapshot work but means less speed
- the live conversion of the vmdk to vhd/xva format shouldn't be too hungry, but more resource are always welcome when time is the issue
Go to the XOA VM , click on the CPU count( 2x here ) , change its value, reboot the VM. You can add some more ram, it will always be useful
- what are you using on the server side ? XCP-ng or xenserver ?
- the process can be sped up by deploying a XO ( from source ) directly on the vmware cluster
- Do you have a proxy to reach internet ? we have a fix in the work https://github.com/vatesfr/xen-orchestra/pull/7551
- do you have multiple vmware datacenter we also have a fix in the works https://github.com/vatesfr/xen-orchestra/pull/7553
if it's something else, we'll do our best to make it work, v2v is an important part of our platform
closed fix(vmxware-explorer): handle multiple datacenter #7553
-
@florent Thank you for the quick reply.
a 5.93.1 version has been released with a few fixes regarding the nfs import
- XOA is currently running version 5.93.1 (I missed the .1 in the original post).
to do a warm migration, the VM must have at least one snapshot . More than one snapshot work but means less speed
- The part about a snapshot being required I did not know, so I just tested it - only results in HTTP 500 errors, but the source VM is not shut down, at least.
the live conversion of the vmdk to vhd/xva format shouldn't be too hungry, but more resource are always welcome when time is the issue
Go to the XOA VM , click on the CPU count( 2x here ) , change its value, reboot the VM. You can add some more ram, it will always be useful- As I said above, trying to change the CPU count on the XOA and choosing to reboot it, only shuts down the XOA (probably because it's own connection to itself if lost) and changes aren't applied. Catch 22.
what are you using on the server side ? XCP-ng or xenserver ?
- Server is running XCP-ng (8.2.1 with latest patches applied).
the process can be sped up by deploying a XO ( from source ) directly on the vmware cluster
- Interesting thought, running the XO on the VMware side, but how could that VM later be migrated to XCP-ng, to maintain pool/host/settings?
Do you have a proxy to reach internet ? we have a fix in the work https://github.com/vatesfr/xen-orchestra/pull/7551
- No proxy.
do you have multiple vmware datacenter we also have a fix in the works https://github.com/vatesfr/xen-orchestra/pull/7553
- Just a single VMware datacenter.
I can try opening a support ticket and hope they can find the issue and/or let know what to do
-
@Carello The ticket will probably reach my desk. And for now I have only one user still stuck (and he's migrating to xenserver so I can't really count this as a miss). Hopefully we'll find a solution for you too , that will improve our solution for every one else
(BTW, I work on Paris time )
-
transfer successfull
There was a misconception the NFS mount should be a remote ( in XO side ) ,not a SR ( in XCP-ng side) -
Great news
Should we switch this thread as solved? -
@olivierlambert I'm afraid I'm still having some issues with migrations, and I'm hoping someone could clearify some things for me.
First, most of the migrations I've attempted, have started with shutting down the VM on the VMware side, resulting in an offline migration.
This does not seem correct, shouldn't the VM be shut down towards the end to synchronize changed data?Secondly, I'm receiving random "Error: EACCES: permission denied" errors at the end of migrations, so the VM is not migrated.
In these cases, the source VM does not get shut down, which I'm guessing is the cause of the error?Overall, I'm starting to think that the import from VMware is not near ready to be used, which is very sad.
-
@Carello Please do not jump to conclusions like this.
Every day we have literally dozens of people using this tool to migrate. It's just there's so many different setups and configuration that it can't be magically working out of the box for everyone. If I understand correctly, your first issue was a configuration issue (not creating the right storage connection for XO). The EACCESS permission denied is likely also a permission issue. Note there's little we can do with our tool to avoid a bad configuration (except improving our doc and assist you). But as you can see, we are committed to assist
-
@Carello
We also didnt get it to work with XO (vSphere 7 and 8). We used the Xen Conversion Manager VM (from XenServer) to do the conversion (With XCP-NG Center). This worked most of the time.When it did not work we used CloneZilla.
-
@rfx77 said in Problems doing live/warm migrations from vSphere/ESXi 7 to XCP-ng:
@Carello
We also didnt get it to work with XO (vSphere 7 and 8). We used the Xen Conversion Manager VM (from XenServer) to do the conversion (With XCP-NG Center). This worked most of the time.When it did not work we used CloneZilla.
The Vates people released Yesterday a new update of Xen Orchestra on the Latest channel (if XOA), you'll need to wait if you require a stable release. With a significantly improved V2V tool, worth checking out to see if this will help.
https://xen-orchestra.com/blog/xen-orchestra-5-94/
Also what edition of VMware ESXi or VMware vSphere are you using? Lower editions of these products have some restrictions which can impact the type of migration possible from VMware to Vates.
-
-
Thanks. The problem is taht we dont have a NFS datastore to use. So we had to do export/import.
-
@rfx77 said in Problems doing live/warm migrations from vSphere/ESXi 7 to XCP-ng:
Thanks. The problem is taht we dont have a NFS datastore to use. So we had to do export/import.
you can migrate without a NFS datastore, but on esxi 6.5+ , you'll need to shutdown the VM before starting the migration
and with vsan there is an additionnal , slower steps : extractig the vmdk to a Remote (in XO ) -
Not looking to revive this topic but wanted to post this documentation I found in case anyone else searching for answers stumbles here like I did. There are too links on this site that address some limitations that are not readily documented in the standard migration documentation.
