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

@poddingue Thank you!

Good to hear block mode did it. If I'm reading XO's troubleshooting page right, that 5-minute wait is a setting you can raise: httpInactivityTimeout under [xapiOptions] in a file like /etc/xo-server/config.httpInactivityTimeout.toml, then a restart of xo-server (https://docs.xen-orchestra.com/backups-and-dr/backup_troubleshooting#error-http-connection-has-timed-out). That path is the XOA one, and I don't know where the ronivay installer keeps its config, so check that first. The page calls it a workaround and says the slow host is the real thing to look at, which could fit your SMR-disk theory, but I haven't tried anything close to a 3 TB qcow2 delta myself. For the close() error, unless I'm misreading the code, XO closes the source after the failed start and only logs a warning before falling back to a full, so I'd guess it's noise from the timeout and not a second bug. The stuck tapdisks look more like one for @Team-Storage, and I don't know if a keep-alive during the delta computation is planned.

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

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

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

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.

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.

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

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

@Goulven I have shared the logs with you over the drive.

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

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.