Problems doing live/warm migrations from vSphere/ESXi 7 to XCP-ng
-
@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.
