zorro

Had what looks like a similar issue on a local EXT (file-based) SR, XCP-ng 8.3, sm-3.2.12-23.5.

Sequence: snapshot of a running Windows VM → disk resized (60 → 75 GB) → snapshot deleted while running. The VM froze.

SMlog showed the live leaf-coalesce failing on the parent resize, then reporting success anyway:

Expanding COW image virt size for VDI <parent>: 60.000G -> 75.000G
qemu-img resize <parent>.qcow2 80530636800
_doCoalesceLeaf: EXCEPTION util.CommandException, Operation not permitted
*** finished leaf-coalesce successfully
Leaf-coalesce failed on <leaf>, skipping

Afterward the VM wouldn't start (SR_BACKEND_FAILURE_46, stale tapdisk), the GC kept failing with HANDLE_INVALID for the parent VDI, and qemu-img info on the parent showed corrupt: true. Windows wouldn't boot after cleanup, so I restored from a veeam backup and moved on.

Hopefully the sm-3.2.12-25.1 fix covers this issue too.

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

The internet check was timing out on the IPv6 address for xen-orchestra.com IPv4 was fine the whole time.

curl -4 -I --max-time 15 https://xen-orchestra.com/ # HTTP/2 200
curl -6 -I --max-time 15 https://xen-orchestra.com/ # couldn't connect

What fixed it was disabling IPv6 at boot, then rebooting so xo-server starts with it already off:

printf '%s\n' 'net.ipv6.conf.all.disable_ipv6=1' 'net.ipv6.conf.default.disable_ipv6=1' | sudo tee /etc/sysctl.d/99-disable-ipv6.conf

After that, xoa check was green, including internet connectivity and no more check for upgrade issues. I'm hoping this fixes my XO Config Cloud Backup. I will report back if not.

17/17 - Internet connectivity: Error: HTTP connection has timed out
at ClientRequest.<anonymous> (/usr/local/lib/node_modules/xoa-cli/node_modules/http-request-plus/index.js:61:25)
at ClientRequest.emit (node:events:519:28)
at ClientRequest.patchedError [as emit] (file:///usr/local/lib/node_modules/xoa-cli/index.mjs:31:17)
at TLSSocket.emitRequestTimeout (node:_http_client:927:9)
at Object.onceWrapper (node:events:633:28)
at TLSSocket.emit (node:events:531:35)
at TLSSocket.patchedError [as emit] (file:///usr/local/lib/node_modules/xoa-cli/index.mjs:31:17)
at Socket._onTimeout (node:net:604:8)
at listOnTimeout (node:internal/timers:585:17)
at process.processTimers (node:internal/timers:521:7) {
url: 'https://xen-orchestra.com/',
originalUrl: 'http://xen-orchestra.com/'
}

XOA Update sometimes failed too but hitting Refresh a couple times got it going.
10/1/2026, 10:03:28 AM: All up to date
10/1/2026, 10:26:26 AM: Start updating...
10/1/2026, 10:26:32 AM: HTTP connection has timed out
10/1/2026, 10:27:14 AM: Start updating...
10/1/2026, 10:27:14 AM: stable channel selected
10/1/2026, 10:27:14 AM: All up to date

I'm waiting for veeam 13.1 release as well. Will move a few things over and test out the native backup in the meantime.