Setting up a solid backup strategy is always such a relief once it's actually dialed in. It's really helpful to see the different approaches laid out like this, especially for finding that balance between reliability and ease of use. This definitely gives some good food for thought for anyone looking to refine their setup.

@hoh This is SOOO long in the tooth........... Always was annoying. Thx for findinf a fix, looking forward to it.

@planedrop why dont you just disconnect the VMDK at source VM ?

@TeddyAstie Attached is the output you requested xen-cpuid -p.txt

@olivierlambert I would think HP servers would be a top tier for IPMI support.... please...

@acebmxer I haven't tried this yet, but liking the menu you just showed!

@JSylvia007 "Fatal error: exception Unix.Unix_error(Unix.EIO, \"read\", \"\")\n" mmmm SR is failing ? can you restore the last known good state of this VM (in parallel of the one in production) and try to backup this restored version ?

UPDATE: its been 2 days and as I suspected the VDI is still waiting to coalesce at a length of 1, The GC does not seem to be cleaning it up. Does anyone have suggestions for how to remove this orphaned VDI and base copy. I'm not interested in saving the VM just cleaning up the remnants of the botched migration and removal.

I am on it , thanks for all the informations

@Kraken89 I will look into the transition from the previous system to the new one maybe that's the key

I am trying to setup the same VxLAN Private Network between two pools. I have been running XO from sources (commit 813514821) for a while now and encountered the same error "No PIF found in center". Therefore I updated to the latest commit 60ba5070c (still using XO v5) and now I was able to create a VxLAN private network that spans two pools without an error. I checked the networks for both pools and noticed that two networks were created per pool, so I was able to create it despite the error from the older XO version. However, using either VxLAN to connect two VMs in different pools doesn't work. Pinging a VM over that VxLAN in the same pool and host works, but pinging a VM from another Pool doesn't work. This is also the case when using GRE, Looking at the ARP Table, it seems that the VMs from different pool do show up, but as incomplete: [image: 1774432891674-screenshot-from-2026-03-25-10-59-34.png] 172.30.0.10 is the VM in the same pool as work (172.30.0.30), 172.30.0.20 is the VM from a different pool. I manually set the MTU size in each VM to 1450 just to be sure. I have two pools with one server each. This is due to CPU feature mismatch. Each host is connected via a bond of two SFP+ Ports (which have default MTU 1500) to a switch that allows all VLANs. Using normal VLAN Networks does work with multiple pools.

@acebmxer Yes, 22 or 24 should work correctly. Some early versions of 24 had issues, but not currently. I'm running 24 and it is working.

@ph7 that is a good news thank you for your patience and help

Great News!!

Ping @Team-Hypervisor-Kernel

@Danp Yes, they are all 'empty': xe vm-cd-list --multiple | grep -i false doesn't give any output.