@nick.lloyd I'll look into the HA support, need to dig into that whats needed to support that. keep you posted

@blueh2o thanks for the log. In that run 16 of the 56 VMs failed this way, and each one names a different missing base, so it doesn't look like one damaged chain to me. That's past what I can work out on my own, so @Team-XO-Backend, this one has a version and a full job log attached above now if someone can take a look.

@acebmxer I haven't run your script, so I can't vouch for the log lines, but the systemctl status check looks like the safer of the two to me. It shows the binary the service is really running. Whichever node comes first in your shell can be a different one if more than one Node is installed. For XOA I'd go with what @Danp said above.

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.

@poddingue Thank you!

Hi, @Velocity1192 . On v6 first: creating and editing backup jobs still happens in XO 5 for now, XO 6 shows the jobs but doesn't create them yet (https://docs.xen-orchestra.com/backups-and-dr/backups-in-xo6). For the schedule, @abudef asked almost the same question earlier this year. @Pilow's answer there is clearer than anything I'd write: https://xcp-ng.org/forum/post/104108. As I read it, you either use one daily schedule plus the "Full backup interval" setting (the full lands N runs after the chain starts), or two schedules on the same job with "Force full backup" ticked on the Sunday one. That second way is how you get to pick the day, and he says not to mix the two. One thing to expect, from @Danp in another thread (https://xcp-ng.org/forum/post/91943) : the oldest backup is always a full and old deltas get merged into it, so for a while you'll see two fulls on the remote rather than weeks 1 and 2 being deleted. I don't think the scheduler can say "every other Sunday". I might be wrong there; someone who runs this kind of plan may know a trick.

@irtaza9 Is this on a single host or a pool? Are all hosts properly time-synchronized? It it related to just one specific storage device or on any, e.g., is the behavior the same on a locally-created SR? Are there any hung tasks causing unnecessary I/O on that storage device?

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.

For anyone else who steps through this, I've also installed the latest xen-guest-agent with the below process. Repeat for each host in the environment, 1 at a time from your Helper VM. ### ssh into your helper ### oc debug node/fedora-cmp-1/2/3 chroot /host cd /var/tmp curl -LO https://gitlab.com/xen-project/xen-guest-agent/-/jobs/6041686376/artifacts/raw/RPMS/x86_64/xen-guest-agent-0.4.0-0.fc37.x86_64.rpm sudo rpm-ostree install /var/tmp/xen-guest-agent-0.4.0-0.fc37.x86_64.rpm mkdir /var/tmp/xga && cd /var/tmp/xga rpm2cpio ../xen-guest-agent-0.4.0-0.fc37.x86_64.rpm | cpio -idmv ### From your helper... DRAIN YOUR WORKERS ### oc adm drain fedora-cmp-1/2/3 --ignore-daemonsets --delete-emptydir-data ### log back into fedora-cmp-1/2/3... ### sudo systemctl reboot ### from helper ### oc adm uncordon fedora-cmp-1/2/3 ### login to fedora-cmp-1/2/3 ### chroot /host sudo systemctl enable --now xen-guest-agent And then from XO this is what your VMs will look like. [image: image.jpeg]

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

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.