I just migrated from 2x vmware vsan hosts and 1x vmware standalone to xcp-ng in my lab and every migration resulted in a stop of the source vm. It's not a big deal for me in our lab, but I had major issues with some VM's never "finished" the migration. Xen Orchestra, commit b89c2 Master, commit b89c2 I noticed that after the task has timed out, the VM that was migrated is often able to start, even tho it was not "finished". Is this expected?

I just noticed I am seeing the same thing on some of my virtual machines. When I view the Disks tab for a vm in the Xen Orchestra 5 ui it shows no items found but XO6 will lists the disks associated with this vm. It only appears to be affecting 2 out of the 4 hosts that I have connected to the xoa instance but is not affecting all the virtual machines of those hosts. It seems to be impacting disks on both local and nfs storage pools. There are no errors reported and the vm's are running fine and I can take snapshots and execute backup tasks, stop and start the vms without any problems. It just seems that the XOA v5 vm disks display is no longer able to find the disks for certain vms. I am running version 6.0.2 XOA build: 20251101 from the latest channel.

Tracked it down to it thinking there was a pool version mismatch... then when I tried to transition to a new master it would fail with Xmlrpc_client.Connection_reset ... digging deeper it was complaining that it couldn't restore from the wrong version. Lots of head banging later... I setup a backup for the pool metadata and forced the backup immediately. TADA... I can now change the master with no issues at all.

Restarting tool stack on master host of remote pool cleared the stuck job and backup was able run failed vms. Support ticket still open fyi.