@mpiton Thanks for a fantasticly quick answer, and detailed as well. I will test this immediately! Update: I can confirm that this was indeed the problem!

@poddingue Thanks for taking a look. Yes it is this part that tells me that it should start the VM automatically once the import has completed. "After the transfer, the VM on XCP-ng side is started:" Followed by, "This process is fully automated, without any human intervention after it starts on step 1." [image: image.jpeg] https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/ But my findings/experience is that the VM does not start once the import/transfer has completed. So either the docs are wrong. Or the function is not behaving as intended. I'm acctually fine either way. As long as I know what to expect. However, I would like to have it auto-start the VMs after transfer completion. Which would make the procedure "Fully automated". Update: Am I assuming correctly that "the XO V2V guide says to start the VM yourself once the migration is complete " you're reffering to, is part of the "test migration"-procedure? Not the acctual production mgiration? Because: "Final migration Run the production migration When you're ready for the final migration: Shut down the source VM completely. Start the V2V migration in Xen Orchestra with the Stop source option enabled. This ensures the final sync happens while the VM is powered off, and prevents any inconsistencies." In my mind doesn't state that the VM should be started manually post-transfer. Great thanks in advance for discussing! Cheers!

We are fully aware of Broadcom's decision to stop providing the VDDK library to the cloud community or to reserve its download to some authorized partners and customers. As much as we regret this decision, we have to respect it. Because it impacts users who need to make backups, we are evaluating alternative options to address this situation. We will provide further guidance as this evaluation progresses but can't share more information for now.

Thanks, keep us posted!

If i recall from my migration I belive thats all there is to it. I know the docs mention about doing a test migration but mine just migrated and it just worked as you stated after making the needed adjustments. Let other chime in but i think you are good to go. And you could delete the snapshot from the vm.

Excellent! It's really cool to see how XO Backup and Replication can help you to migrate easily

Hi, everyone Thank you for your help. I had a flux that was blocked by our firewall. The button worked after that. But it doesn't explain why I lost this configuration and had to reinstall it. Thanks again.

Maybe, the view from hypervisor level would be interesting, too: # xenstore-ls -f | grep -i driver Will list the drivers for each domain. # list_domains Gives the VM UUID for each domain id.

Following up since the situation changed: QCOW2 went GA in XO 6.5 (released 2026-05-28), so the old ~2TB VHD ceiling is gone. A disk at exactly 2TB, and well beyond it, is fine now without shrinking to 1.99TB first. When acebmxer and john.c replied, it was still a release candidate; it's the stable story now. I haven't migrated a disk quite that size myself, so I won't promise it's totally painless, but the format limit that was blocking you isn't there anymore. The release blog has the details if you want to read up before the migration: https://xen-orchestra.com/blog/xen-orchestra-6-5/

@julienXOvates Thanks for the quick reply, that’s very helpful!

@tsukraw I am taking the ticket and will keep you informed as soon as possible

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.

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 ?