@Danp
So, that's the "best" way? Backup the meta-data with XOA, rebuild the OS drive - add the "new" server into XOA and restore the meta-data back to the new install?

(I'm not doubting it is, just wanting to be sure we're understanding each other fully.)

Seems straight-forward - but there's a ton of things I've done over the years that "seemed" pretty straight-forward that turned out to be anything but, and at least occasionally found I had no way back. 🙂

You should be able to delete the snapshots without causing any harm. A couple of things to keep in mind --

If the snapshot is associated with an existing backup job, then the next run of that job will result in a full backup instead of a delta

It may take some time for the snapshots to coalesce following deletion, so this could still affect your backups until they are completely removed

If you want to delete the backups associated with the old job, then you can from the Backup > Health tab in XO

Hi,

Xen isn't Linux. When you boot on XCP-ng, you boot on Xen first, then the "control domain" will boot first (aka Dom0, aka what you think is the host but it's not).

This has to be implemented inside Xen, and I'm not sure that's the case. Let me ask around.

What do you mean by moving? Moving the disk or just the VM memory?

@olivierlambert Thanks. As always you guys are great.
Thanks for this opensource project!
Tasks have cleared up.

Both secure boot support and the fix for this KB installation are now available for testing: https://xcp-ng.org/forum/post/41541

@s-pam said in ova problems:

@crazytoo Best way to be sure it to boot the VM using a live-cd, for example systemrescue-cd or ubuntu live-dvd. Then you can use tools like gparted to inspect your disk image from inside the booted vm.

That's exactly what I advised to do earlier, but it seems it was missed the first time 🙂 I think that's the best approach to understand what's going on in the VM disk.

Answered on the XO forum, thank you 🙂