@mpiton Thanks for a fantasticly quick answer, and detailed as well. I will test this immediately! Update: I can confirm that this was indeed the problem!

@FritzGerald Thanks! Running systemctl enable --now ups-driver.service got ups-driver.service going, then following the instructions you provided earlier got the rest of the two services running, even after a reboot. I'm now able to run upsc apc@localhost and get the correct output listing all the properties of the UPS even after a reboot.

@jacob.becker said: Hi! After the XOA update to 6.8.2 (Stable), the Backup of the pool metadata fail with Error: Body Timeout Error after aprox. 5 minutes. Other Backup Jobs run without issues. @jacob.becker On the latest channel for XOA updates version 6.9 (6.9.0) has a fix for Body Timeout Error issue, no sign of a fix in 6.8.0 to 6.8.2 version series. Change channel and you’ll have the fix or open for Vates staff via PM a support tunnel access so they can patch your 6.8.2 with the one specific for this version. This is an SERIOUSLY urgent action to fix the backup issue, but the Critical part is that it also fixes an important security vulnerability (VSA-2026-044).

@zorro said: *** finished leaf-coalesce successfully This is misleading, this is printed by _finishInterruptedCoalesceLeaf that is handling cleanup after the leaf coalesce failed. Thank you for the information, we have a fix for the interrupted coalesce leaf in the next release that might help, I'll also try to reproduce to see if it's the same behavior.

@poddingue said: Thanks for posting the fix. The same thing came up in an older thread, https://xcp-ng.org/forum/topic/9957, where disabling IPv6 also made xoa check go green. @HamiltonWDS explained a likely reason in https://xcp-ng.org/forum/post/87831: Node tries the addresses with a short timeout and can end up on the IPv6 one. Your curl -6 test helps a lot here, because it shows IPv6 doesn't connect at all on that network, so it's more than a slow path. Turning it off in XOA seems reasonable if you don't use IPv6 there; if you do, I'd guess the router side is where it really needs fixing, though I could be wrong (still haven't migrated to IPv6 myself ). Curious whether it sorts out the Cloud Backup too. XOA is using our management network where ipv6 is not needed and not enabled. Looks like our cloud backup finally ran for the first time in while too.[image: cloudbackup.jpg]

@pierrebrunet Thanks for the update. So is there any way to run the reclaimSpace function (i.e from the XO CLI or something, without having to build a whole REST API application or whatever that involves)?

Hello, this issue has been fixed in XAPI 26.1.19-1.1 available in the testing updates. For now you have to configure your VMs manually (https://docs.xcp-ng.org/troubleshooting/common-problems/#pci-passthrough-error-unsupported-msi-delivery-mode-7) but the fix will be activated by default in the future.

@ovicz Which exact version of XAPI do you have? If you have 26.1.19-1.1 from testing, you should be able to fix it by setting hvm-pirq=false using the instructions here: https://docs.xcp-ng.org/troubleshooting/common-problems/#pci-passthrough-error-unsupported-msi-delivery-mode-7