@geometry game 2 This usually happens when dependencies are out of sync after pulling updates. Did you try removing node_modules and the lock file and then running yarn install again before starting XO?

@simonp - Can you reshare the dashboards. The link says json is not available for any of these dashboards,

I've seen this happen after a BIOS update or if a CMOS battery starts failing. Sometimes the motherboard resets to 'Legacy' instead of 'UEFI' (or vice versa), and GRUB just loses its mind because it can't find the partition it expects. It’s worth a quick check in your firmware settings to make sure the boot mode and the drive order haven't shifted on you.

That is a frustrating loop to be in, especially with TrueNAS. Usually, when the VM fails to start after a change, it’s because XCP-ng is trying to pass through a PCI device (like an HBA) that isn't being released properly by the host. Have you checked if the "hide" parameters in your grub config are still correct? Sometimes an update can reset those, and the host grabs the controller before the VM can. Another thing to try is toggling the BIOS/UEFI mode in the VM settings - TrueNAS can be picky about that depending on which version you’re running.

@fnf games If it hangs right after detecting the disk, it could be a bootloader or filesystem inconsistency from the snapshot state. Can you try booting the VM with a recovery ISO to check disk integrity or rebuild the bootloader?

This issue appears to have been resolved by a recent change.

While I was updating all the pools, a micro-update for 5 packages was released again. They come out every week now. Same issue with basic migration. Now it impossible.

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

@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).