@poddingue Thanks for running the -31 numbers — good to have it confirmed that the ttyS0 removal stays worth ~3-4s even with the clock fixed. Agreed on not rushing -proposed to production; we'll pick up -31 when it promotes and keep the cloud-init tweak permanently.

Veeam scheduled a remote call with me and pulled more log files. Of coarse when we ran the backup job twice in a row both times al vms were successful. Veeam needs to baby sit our backups :). The call was cut short do to internet going down. I have uploaded the logs and waiting to hear back. Update - Veeam took alot more logs from Veeam and from xcp-ng pool. Their response back - I've got someone else getting similiar results, so I'm providing both of your logs to get some insights. Basically when you see the error, it's because something happened to the bitmap we left behind on the previous run and so next run, we re-read the entire disk. I've not found anything super clear to what's going wrong with the bitmap and why its gone, even from the Xen server logs, so I'm hoping from QA's eyes might see what I might be missing. I will keep you posted if they have any details.

Thanks for actually booting one, that's the bit I skipped. -84s versus -10s without console=ttyS0 matches the Ubuntu ratio, and it's the first EL10 number anyone has measured rather than read from the source. That settles the question I left open. A real-world measurement is vastly better than a source-code read, right? Thanks for the backport request, too. Since CentOS Stream sits upstream of RHEL and Rocky, if the backport lands there, it should be the earliest signal that the rest of the family will follow.

Yes. I removed pci=nomsi entry from grub. I've tested on a Debian Forky and CentOS Stream 10 VMs with gnome and an intel alderlake igpu passthrough no issues at all.

@anthoineb, We checked both SMlog and xensource.log for the two latest incidents on hypervisor 172.30.50.181. There was no VM or storage pause/unpause operation before either stall. The only matching pause/unpause pairs were part of our later forced VM.hard_reboot: 2026-08-19, VM 172.30.52.185: stall confirmed around 20:24; pause at 20:36:37 and unpause at 20:38:12. 2026-08-20, VM 172.30.52.182: stall confirmed around 20:24; pause at 20:30:07 and unpause at 20:31:26. The first related VDI operations in SMlog were also the vdi_deactivate actions initiated by those reboots. Therefore, we do not see a pause/unpause immediately before or at the onset of either lock.

Thanks for the feedback.

@poddingue Sorry for my delay; I appreciate the response and insight. Concerning the Wiki entries, you appear to be correct and the wiki has been updated accordingly and the offending entries removed - perhaps it was my bad google-fu directing me to the blog post from more than 10 years ago (which then referenced the wiki lol) so that's on me and for that I apologise; I do note though that it's still listed in the Feature Matrix - https://xen-orchestra.com/#!/featuresmatrix (Edit: and the Advanced features section ) I'll endeavor to raise this in the appropriate spot in gitlab, and if there's any interesting movement or activity I'll try and post here for posterity. Regards. CAPS

It looks like this is identified and solved, I'll test on a new version of XO next week at some point, but I just wanted to confirm that I've been seeing what appears to be the same problem. This hasn't affected any of my full, delta or mirror backups, on any of the NFS targets - but it does affect two different Pool metadata & xo config backups. Both on different NFS targets on different schedules. It's an infrequent failure, sometimes not failing for a couple of days, but sometimes failing up to 3 or 4 times per day - this is on an hourly schedule. [image: 1787394387803-912ddd51-e6c1-4a62-8529-79d6b2fe8ad0-image.jpeg] My most recent failure on the hourly job was yesterday morning, the one before that was almost 24 hours earlier. This is currently on Xen Orchestra, commit 24913 but it was also noticeable on a version from the end of July. From what I've read, I'm guessing the fix will be in the main branch soon enough and an update will solve it, but if there's any useful information I can provide, please let me know.

@olivierlambert I'm not sure what I'm looking for in the XCP logs, and these are busy hypervisors so fishing stuff out is difficult. I'm gonna build a new machine that's not doing anything else and try and get a clearer view.

That should be it, tks @poddingue

@pierrebrunet This week I only got 500 errors affecting 5 VMs. These 5 VMs were retried at VM-level and one fo these failed again (it failed to backup since I only have set 1 retry). I'm now looking into connection and bandwitdh to B2. I'm only reaching 200 Mbps to B2 with my current ISP so I'll tune concurrency so I reach those 200 Mbps with fewer VMs in parallel, making each single VM transfer faster. Concurrency was set to 8, I'll try with 3 VMs in parallel this weekend. Tks, Pedro

Intel needs some special handling to support physical displays with PCI Passthrough; I don't know much of the details, but on "recent" machines, some bits are missing according to : https://lore.kernel.org/all/20260802050824.10554-1-brchuckz@aol.com/

@poddingue said: What I can't tell you is what set that particular combination on your VM in the first place. Does it ring a bell? I have no Idea. I had it on "Protect from accidental shutdown" but turned that off again, later. Doing this again (on, off) helped, as you said. Thank you so much!

Nice! Have you tested the snapshot, revert and so on?

@seanmcg182 's post might be the answer to the original question, two years late. Your lspci -s 0000:05:00.0 -v at post 8 shows (rev ff) and !!! Unknown header type 7f, which is the same pair he had, and in his case it came from bifurcating the wrong PCIe port in the BIOS rather than from anything XCP-ng was doing. He says the unknown header is what then produced the device or resource busy error on VM start, which is the error you opened with. I don't know whether your board exposes bifurcation the way his X10DRH-CT does, so it might not transfer at all. @kuznetcoff777 if that machine is still around, it'd be worth a look either way.

Update V0.3.0 Deploying to a New VM (--deploy) If you don't already have a Linux VM to install into, --deploy builds one for you. Run it from your own workstation — it is the only operation in this script that does not run on the machine Xen Orchestra ends up on: git clone https://github.com/acebmxer/install_xen_orchestra.git cd install_xen_orchestra ./install-xen-orchestra.sh --deploy It will ask for your pool master's address and root password, let you pick a storage repository and network from what the pool actually has, then ask for the VM's size, admin account (optionally with a password), where to clone this repository inside the guest, and its static address. From there it: Creates the VM and streams a stock Debian 13 cloud image from cloud.debian.org straight into its disk. The download runs on the pool master, so the 3 GB never crosses your workstation's link and never lands on dom0's root filesystem. Attaches a cloud-init config drive that creates your admin user, installs a freshly generated SSH key, applies the static address, and clones this repository into the guest — either /opt/install_xen_orchestra or /home/<admin>/install_xen_orchestra, whichever you pick. SSHes in and runs --install --non-interactive, streaming the output to your terminal so you see the build as it happens. Verifies XO answers on /signin, then detaches and destroys the cloud-init config drive — it has served its purpose, and it holds the admin password hash. If the guest refuses the hot-unplug, you get the xe commands to remove it by hand rather than a failed deploy. Changing settings the prompts don't cover --deploy only asks about the HTTP/HTTPS ports and the git branch. Everything else the VM is installed with — INSTALL_DIR, SERVICE_USER, NODE_VERSION, SSL and backup paths — comes from a base config, and you get to see it before anything is created on the pool: The base is sample-xo-config.cfg from the repo. If you also keep an xo-config.cfg beside the script, you are asked which of the two the VM should start from. (Check its paths first — they were written for whatever machine it came from, not a fresh Debian VM.) Right after the prompts, --deploy offers to open the generated config in your editor ($EDITOR/$VISUAL, else the base config's PREFERRED_EDITOR, else nano/vim/vi). Save and quit and the VM is built with exactly what you left there. The edit happens on a throwaway copy in a temp directory, so neither the tracked sample nor your own xo-config.cfg is modified. Changing the ports in the editor is picked up too — the review screen, the post-install check and the summary all follow what the file ends up saying. Requirements The pool master must have outbound internet access. A free static IP — this is required, not optional. A stock Debian cloud image has no xe-guest-utilities, so the host cannot report a DHCP lease back and the script would have no address to install over. On your workstation: ssh, scp, ssh-keygen, and an ISO writer (genisoimage or xorriso). Only the ISO writer might need installing, and that is the sole reason --deploy would ask for sudo — nothing else about this operation touches your machine. sshpass is optional: with it you are asked for the pool master password once, without it ssh asks a second time. Afterwards the VM contains an ordinary checkout of this repository, so updates work there exactly as anywhere else: ssh -i xo-deploy-<hostname>.key <admin>@<ip> cd <clone dir> && ./install-xen-orchestra.sh --update The generated SSH private key is saved next to the script as xo-deploy-<hostname>.key (git-ignored). Keep it, or add your own key to the VM and delete it. The admin account's password is optional and asked for during the prompts. The account always gets the generated SSH key, so a password only matters for the VM's console in XO Lite or XCP-ng Center, where no key can be offered, and for su. Leave the prompt empty for a key-only account. If you do set one, a second prompt asks whether SSH should accept it too; the default is no, keeping SSH key-only. Setting the password needs openssl (or mkpasswd) on your workstation — without either, the prompt is skipped and the account stays key-only. The VM is created with SERVICE_USER=root (the current default) and XO's usual admin@admin.net / admin starting credentials — change that password before putting the VM to use. To deploy a different Debian release, set XO_DEPLOY_IMAGE_VERSION and XO_DEPLOY_IMAGE_RELEASE, or point XO_DEPLOY_IMAGE_URL at any raw cloud image with cloud-init installed. Checking a host before deploying --deploy depends on XAPI behaviour that the test suite cannot exercise without a hypervisor. If a deploy fails, or you want to check a host first, run the probe: ./tests/probe-xapi-deploy.sh --host 192.168.1.10 It verifies each assumption in turn — SR and network enumeration, the pool master's internet access, vdi-import from a pipe (round-tripped and checksummed, not just exit-code checked), the /import_raw_vdi HTTP fallback, and VM creation with the boot and memory parameters deploy sets. Everything it creates is named xo-probe-<run id> and destroyed on exit, including on failure; it never touches objects it did not create, and never starts a VM.

@dinhngtu Just wanted to pass along some feedback from trialing the newest version (9.2.350) -- in case it's helpful. When comparing to the previous version (9.1.200 -- and earlier versions as well) on Windows 11 Pro VM (with latest updates), this new version results in noticeably slower VM restart and shutdown times (at least when monitored via xenadmin [on Windows] and xenadminqt [on Linux]). ... Just remembered I updated XCP-ng at the same time to the latest iteration, perhaps the slowdown may be related to that.