It's a been a while since this thread has been updated, so I figure I should share what I've learned. First: here's a script which reproduces the bug reliably and includes steps to revert: https://gist.github.com/dmeiselman/ecb35ffcb675c38e6eeb14292948c2e3 Don't run this on your production cluster. Here's my understanding of this bug and it's current state: Some operation sets the snapshot_of metadata field of a valid snapshot to NULL (We can do this intentionally by making a VM, taking a snapshot of it, then deleting the parent disk.) If you perform a revert of this invalid snapshot, revert's "Updating the snapshot_of fields" step looks for VDIs whose snapshot_of matches the snapshot's source disk, so it can relink them to the new disk. If the source is NULL, the search becomes "every VDI with NULL", which matches ISOs, base images, ordinary VM disks. Congrats, every real disk and ISO in every SR now looks like a snapshot. Now these disks have a value set for snapshot_of which means XOA hides the VDI in the web UI. The fix is to delete or clone the super-parent, and all of its snapshots. sr_scan will correct the metadata for all the VMs and ISOs and you're back where you started. This happens in line 401 of https://github.com/xapi-project/xen-api/blob/v26.1.19/ocaml/xapi/xapi_vm_snapshot.ml#L389-L408 PR 7290 https://github.com/xapi-project/xen-api/pull/7290 has a fix, which looks like it's coming in xapi v26.1.21. (It's worth reading the Pull Request, as it has a more graceful description of the issue, it really helped me wrap my head around it.)

Update: switching the remote to “multiple data blocks” fixed the 2 TiB overflow. The full backup now succeeds (≈1.1M blocks, 13 h) and file restore works. However, the next incremental always falls back to a full The delta export request gets no data for exactly 5 minutes, then undici’s body timeout fires. So “can’t compute delta” is actually a timeout. My guess is that the host takes more than 5 min to compute the qcow2 delta of a 3 TB disk before sending the first byte (single SATA SMR disk, local EXT SR). XapiQcow2StreamSource.close() throws because the source was never initialized. In earlier attempts, this may have left tapdisks for the qcow2 snapshots stuck and attached to dom0 (tap-ctl close timing out, SR_BACKEND_FAILURE_1200). I had to kill them manually before the VBDs could be unplugged. CBT is disabled on all VDIs. Is there a way to increase this timeout for qcow2 delta exports, or is a fix planned (e.g. keep-alive while the delta is computed)? Is the close() error on an uninitialized source a known bug? Same environment as above (XO from sources 3923756ff, XCP-ng 8.3.0, sm-3.2.12-25.1).

Sharing some results. I enabled this on my homelab server, a Dell R630 with Intel Xeon E5-2630 v4 (Broadwell). No adverse impact noticed. The CDM results on Windows is higher than previous runs however, I do not go in depth with I/O benchmarking. (I am using the latest win-pv-drivers on Windows and the rust-based guest tools on Linux) Controller is in HBA mode. VM SR is using SMAPIv3 (ZFS, RAID-0, noop scheduler) [image: R630_XCP-ng_APICv.png] CDM results. Windows Server 2019 4 vCPU/8GB RAM/single VHD: [image: 2610_WIN2019_ZFS.png] I installed ScyllaDB on Alma Linux 10.2 (4 vCPU/8GB RAM & two VHDs, ScyllaDB uses a dedicated drive for data) with io_uring enabled and noop scheduler set on VM. Here are the IOTune results from the ScyllaDB installation: Measuring sequential write bandwidth: 826 MiB/s (deviation 13%) Measuring sequential read bandwidth: 1061 MiB/s (deviation 6%) Measuring random write IOPS: 50791 IOPS (deviation 11%) Measuring random read IOPS: 62977 IOPS (deviation 16%)

@MrQ said: @jr-m4 thank you so much for testing this updated driver. Just to make sure, I understand now that you confirm the driver is working as expected and the issues you had were not related to it? Or are there any problems still with this new driver? Many thanks again for spending the time to test and report. Hi Yes. I believe I was chasing a red herring of my own doing. I have not found anything actually problematic with this driver at all.

@poddingue Thank you!

Thanks for the heads-up. If you built XO from sources, the docs say to keep Node on the latest LTS (https://docs.xen-orchestra.com/getting-started/install-from-sources#nodejs), so it's worth moving to the patched release on whichever line you run. For XOA, I don't know how fast the appliance picks up a new Node release, but I know something's cooking.

Hello Christof, Swapping the disks between the two VMs shows the problem follows whatever runs inside, not the VM itself. Next I would run xe vm-param-list uuid=<vm-uuid> on the host once with HAOS booted and once with Debian booted, and diff the two outputs. Fields like os-version, PV-drivers-version and networks are reported back by the running OS, so they change with the guest. My guess, and it's only a guess, is that one of them comes back in a shape Commvault's parser doesn't expect: "input string has the wrong format" is what .NET says when it fails to read a number. If you find the field that differs, Commvault support would have something concrete to work with.

OK, marking this solved... It was the phantom reboots causing issues because the tools were not fully installed, only thing I can't understand is why only 2 out of 3 Windows servers would quit. Any way, got the Xen Tools updated and a couple reboots later, everything is working again. Also I can now report that a bug that was fixed maybe a year ago is confirmed to work in my system. The bug was backing up a Windows VM that had a lot of empty space in the drive (over 250GB free) and turning on compression. It would time out counting zeros because it thought the process wasn't doing work. Both of these VMs are now compressing with zstd, one of them is substantially smaller now, the other only shrunk about 20GB. Because of the way Windows uses the drive, these are all full backups. The differential never seemed to be small because Windows does a lot of changes on the drive (there is a post about this somewhere in here from Olivier).

The UEFI and possibly SecureBoot requirements on a lot of stuff and going to turn a lot of old systems into garbage. Also going to be an issue when more current stuff gets upgrade from 8.3 in BIOS mode to requiring UEFI for version 9. That's the boat I'm in for production. Alma and openSuse may be a few of the last holdouts allowing v2 and BIOS boot.

@Tristis-Oris said: @DustinB said: 14 year old controller it supported and has a driver. Whats wrong? I can't find that storage adapter on the HCL, were you able to? But the summary I have here is replace the old really old adapter. How reliable can't this card still be after working for so long?

Hi, This was fixed in Latest. But if you need to stay on Stable, you can open a ticket to have a patch.

@julienXOvates said: Just discussed this with @nathanael-h; I would strongly recommend using the load balancer plugin in XO and create some VM-to-host affinity rules, so that your CP VMs are running on different hosts ! So when the RPU comes you would have minimum impact. Yeah the Load Balancer plugin is an option, though not in my plan. I could certainly get it by using XOCE for free though. I wonder if Host Affinity might work as well...

@dinhngtu Thanks for fixing the note. The IP loss did happen on 9.6.0. On the first boot after I set has-vendor-device=false, the guest still reported tools 9.6.0 build 19 (xenbus 9.1.13.23, xenvif 9.1.15.8, xennet 9.1.8.6), and both static IPs were already gone: the main NIC was on DHCP and the second NIC had a 169.254 address. XenClean and the 9.2.385 install came after that.

@willamcorlin Hello, The fix for CVE-2026-46243 has gone through the entire standard release process, which includes: Review by at least 2 developers. Unit testing within the package (if available). End-to-end testing in the CI (xcp-ng-tests). Several days of user testing. And since the release, we have received no feedback suggesting any potential regression. (This does not mean that the risk of a regression is zero.) If any issue arises, please do not hesitate to get back to us. Respectfully,

@poddingue Thank you!

@ma_ron said: Hi, Xen Orchestra, Community 51bb8 - back up logs and statuses are missing in the GUI. backups are done as seen exist available at the restore page. what can be the issue? Hello @ma_ron - That commit is 30 commits behind the current master commit. I suggest updating and trying again.

@JamesG, I'm the one who marked it solved, so here's what I meant. What Teddy showed in https://xcp-ng.org/forum/post/109066 is that there's one thing to do on the XCP-ng side for the B50: turn HVM PIRQ off for that VM (xe vm-param-set uuid=<vm-uuid> platform:hvm-pirq=false, then reboot the VM), as described on the docs page he linked: https://docs.xcp-ng.org/troubleshooting/common-problems/#pci-passthrough-error-unsupported-msi-delivery-mode-7. With that, his benchmark came out normal for the card, and the Gen1 x1 you see inside the guest is something QEMU makes up, not the real link (his earlier post: https://xcp-ng.org/forum/post/106479). It doesn't mean every problem is on the guest side though: @pandusen tried the same setting (https://xcp-ng.org/forum/post/109084) and still had driver crashes on headless distros, and I don't know why. If you try it on your B50 and post what you see, that would help tell the two cases apart.

Glad it's working, and thanks for posting the script, the next NUT user will want it (I hope I'll be able to experiment with NUT in the coming weeks, so I could very well be "the next NUT user"). I tried the PBD part on a lab host running 8.3: xe pbd-list never prints a storage-type line, so that grep finds nothing and step 2 quietly unplugs no PBDs. The 2>/dev/null hides it, and --force isn't an option pbd-unplug knows about. My wild guess is that ejecting the CDs is what fixed it for you. If you want the unplug to really happen, going through the SR type works on my side, though I only tested it against an ISO SR, not SMB: H=$(xe host-list hostname=$(hostname) --minimal) for t in nfs smb iso lvmoiscsi; do for sr in $(xe sr-list type=$t --minimal | tr , ' '); do for pbd in $(xe pbd-list sr-uuid=$sr host-uuid=$H currently-attached=true --minimal | tr , ' '); do xe pbd-unplug uuid=$pbd done done done Block iSCSI SRs show up as lvmoiscsi, which is why it's not iscsi in the list. @Forza's point about hard mounts may still bite if the share is already gone when the unplug runs; I don't know enough about the SMB side to say.