Good moaning... The solution was pretty simple: a toolstack restart on the master (xcp83) did get all back on track and it now allows me to move the systems with a simple shutdown/start.

@MajorP93 This was also my thought, the disconnection method you mentioned, I was just wanting some feedback about that. I do have to be a bit careful because the migration must happen and then the VM on VMware must go back online while I work with the vendor to migrate all the rest of the data. As for the bigger than 2TB issue, that won't be an issue for me. This VM is HUGE but it's because it's thick provisioned and no longer needs to be, the new VM will have like 8 disks but none of them will be over 2TB (most will be less than 100GB). So I am thinking using V2V and just powering off the VM on VMware, disconnect the unneeded VDIs, then migrate, then reconnect those VDIs and power the VM back on.

@blueh2o Ooops, sorry - I read your message the wrong way around. You're right, that sounds really weird in your case....

Found issue in my script all seems to be working now for me just no vmware vm to test import on

This was related to a very large number of snapshots attached to the VMs. This was cause by a bug with backup not cleaning up snapshots if an iso was attached. I was told this was fixed with the latest update.

@ItzJay in your journalctl -i xo-server log you should have something like nbdkit logs of ${diskPath} are in ${tmpDir} where tmpDir is something like /tmp/xo-serverXXXX/stderr can you post the file ? alternatively, you can open a support ticket

@florent root@xo-server:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm root@xo-server:~# dpkg -l | grep gnutls ii libcurl3-gnutls:amd64 7.88.1-10+deb12u12 amd64 easy-to-use client-side URL transfer library (GnuTLS flavour) ii libgnutls30:amd64 3.7.9-2 amd64 GNU TLS library - main runtime library ii libsrt1.5-gnutls:amd64 1.5.1-1 amd64 Secure Reliable Transport UDP streaming library (GnuTLS flavour)

@rniesen Do you mean occasional hangs? Yes, Server 2025 is known to hang if these options are not present.

@benapetr said in Import from VMware err: name: AssertionError: Expected "actual" to be strictly unequal to: undefined: Hello, since this never had a clear resolution, here is explanation of the bug and why it happens: There is a bug in disk iteration in that XO vmware plugin (somewhere in that esxi.mjs I don't remember exact location) - it basically expects that all disks of VM exist in same datastore and if they don't it crashes as the next disk in unexpectedly missing (undefined) Workaround is rather simple - select the VM in vmware, migrate -> storage, disable DRS (important) and then select any DS that no disks current exist on. If you select and DS that is already used by same VM it will sometimes not get fixed! It also may happen even if VM is "apparently" looking like it's on single DS, even if it reports as such, still try to migrate it to another DS, and disable DRS so that really all files, even meta files are in same directory. Then run XO import again, it will magically work. thanks you for the input we were under the assumption that all the disk of a VM are in the same datastore the fix should be too hard now that you did the hard work edit: card created in our backlog, I will take a look after the release to see how hard it is to implement

@yeopil21 you can target vsphere it should work The issue here is that XO fail to link one of your datastore to the datacenter is it XO from source or a XOA ? you should have in your server logs something like can't find datacenter for datastore with the datacenters and the datastore name as detected by XO are you using an admin account on vsphere or is it a limited one ?

@florent said in vmware vm migration: @acebmxer yes after the first migration, XO knwo that the migration is incomplete and that you may want to finish it later. But if you start this VM direvtly , it will write some data, thus it won't be in sync anymore with the Vmware snapshot. Then XO won't be able to resume You can start a copy of the VM ( XO will handle it for you ) and delete the copy when you're done My advice is to migrate this VM to the right SR and then do the resume. But keep in mind that the V2V tool is intended to target only one SR, so migrate all they disk to the same SR, and select the right one when resuming the V2V. You can change the network after My previous migration was successful with no issues. Previously test vm was fresh install so no vmtools installed. But I did shut the vm down myself prior to starting the migration. VM boots no issues no prompts. This time I decided to follow the steps listed in the documentation as i have been following the changes and updates for the v2v migration. Following the steps as mention XO presented me with that prompt which was not mention in the documentation. As i was typing the post to gather my information it was then i noticed i did not select the proper destination SR and the appropriate nic/vlan for networking. So I noted that in the post. With the assumption i could correct that on the final migration. With that said the I guess the documentation should state - Start vm to test if boots, etc.. When prompted choose "Start a copy". When done shutdown vm and remove.

@dinhngtu That's great, thank you. I think I'll wait a bit before switching tools. Everything's working perfectly at the moment. If you need me to test anything, just let me know. I'd be happy to test it when I have time.

@florent I'll send you a link in DM, hope it helps with something. If not, it wasn't too much of an effort, thanks for your time so far

@snk33 Excellent news!

Thanks @olivierlambert , really appreciate quick help. VM migrated successfully.

Ah indeed, labels are honored even in the case of a warm migration. We used it ourselves when we migrated from Intel to AMD CPUs, it was really the best compromise betweeen live and cold (especially when you change the CPU vendor). Glad to see it's helping many people and companies now

@tsukraw we will have to improve the doc First migration : [vm source] => [vm on xcp] Check [vm source] => [vm on xcp] => [copy/clone of vm on xcp] test on [copy/clone of vm on xcp] <-- remove [copy/clone of vm on xcp] Final migration stop [vm source] launch the same migraiton. The data already transfered won't be retransfered applues the fixes you had to do during previous test start [vm on xcp]

@florent yeah that is what i did deploy xo-ce while waiting for a response. I still have 3 more vms to migrate. I so i will continue this route for the migration. Thank you for the confirmation.

@dinhngtu Thanks. I did verify that it does not have the revoked version on any of the hosts. I've also verified that this is only occurring with Windows 2025. I can V2V Windows 2022 or any Linux distribution that we've tried, without secure boot issues. Also, a fresh installation of Windows 2025 doesn't have the issue. I've opened support ticket number 7747017 for this issue. Hopefully someone can get it figured out. Thanks. Allen B.