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

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

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.

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

Great News!!

Ping @Team-Hypervisor-Kernel

@User-cxs si ici :[image: 1774010356739-c9d11a94-06d8-4a3c-b191-f95b2e2ef6f7-image.jpeg] tu DISABLE le serveur. tu nous confirme que c'est "comme" le probleme que tu constates ? un XOA tout vide en page d'accueil ? tu re ENABLE, et ça reviens ok ? tu n'as pas de probleme réseau / micro coupures / host distant au XOA (ipsec/openvpn?) ? la déco/reco que tu as me fait penser a un simple probleme réseau (si ça reviens tout seul et aucun autre impact...)

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.

@gduperrey Worked swell, thanks

@dinhngtu @teddyastie Do you have a time line / rough estimated release date regarding Rust-based xen-guest-agent version 1.0? Currently evaluating if I need to switch my Linux guests back to Citrix guest tools in the meantime. Looking forward to a reply. Thank you in advance.

@florent I rebuilt my XCP hosting environment (everything is faster and bigger stuffed into one rack).... and this issue is now worse. The main changes to this new setup are 2x40Gb networking, faster NFS NVMe NAS, faster pool servers, more memory, much faster CR destination machine with ZFS. Running XCP 8.3 (March 2026 updates) and XO (master a2e33). Replication is leaving many attached to control domain every day with NBD connection set to 2. Changing it to 1 seems to resolve the issue (no more stuck to control domain).

@anthoineb thanks very much! Definitely has us sharpening our cli skills in the meantime….