Yes it works Thank you very much, great job Tested on Ryzen 9 9950X / AMD Raphael iGPU Tested the new experimental iGPU passthrough packages. - CPU: AMD Ryzen 9 9950X - iGPU: AMD Raphael (1002:13c0) - XCP-ng: 8.3 - Guest: Bazzite AMD - VBIOS: extracted from the ACPI VFCT and supplied as /root/vbios.bin - iGPU passthrough: working - AMD amdgpu driver: working - Physical HDMI output: working - Bazzite desktop displayed successfully on the physical HDMI port. Ubuntu 24.04.2 was able to initialize the GPU and Vulkan/RADV detected the Raphael iGPU, but the HDMI output went black when the graphical desktop started. Bazzite worked and provided a stable display output. So on my Ryzen 9 9950X, the experimental packages appear to successfully enable Raphael iGPU passthrough and physical HDMI output.

@herhin2017 said: @john.c Your absolute wright, i do my best and train about 25 young engineers per year on linux (we use debian). I also see more and more startups or small companies building their infrastructure on linux. Best greetings from austria It may be worth getting in line and noting the mention of EFI based servers for official Vates support with XCP-ng version 9.0 and above, in government reports. That way when the school’s hardware is refreshed it can be ensured that your provided with EFI capable servers, in time for XCP-ng version 8.3 EOL. I personally are already ready for XCP-ng version 9.0 due to my servers being Dell PowerEdge R620 for XCP-ng hosts. Along with Debian version 13.6 on the VMs. While using a Dell Precision 3590 to manage those systems. The “wright” makes your above now sound like a wheel wright, and its profession instead of “right” in for when correct or agreeing with someone or something.

Update - changes are live in the dev branch now. So figured out the update / switching branches for the proxy by connecting the proxy to my xoa free account. That triggered the available update to next version. From there I found the command that needs to be ran on the proxy to switch back and forth... [image: Screenshot_20261009_143546.png] Latest branch [image: Screenshot_20261009_144414.png] stable branch [image: Screenshot_20261008_202716.png] Backup job ran sucessful. 2026-10-09T17_48_25.447Z - backup NG.txt After the proxy has been deployed... The proxy has been registered with your Xen Orchestra instance. You can manage it from the Xen Orchestra web interface. Next: register the proxy's updater and move it to the 'latest' channel. On the pool master (IP), set a password for the proxy's 'xoa' user (choose your own) and reboot the proxy VM: xe vm-param-set uuid=UUID xenstore-data:vm-data/system-account-xoa-password='<your password>' xe vm-reboot uuid=UUID SSH to the proxy as 'xoa' (IP) and run: sudo xoa-updater register - This registers it with your vates account. sudo xoa-updater configure-channel xo-proxy-appliance-latest - set to latest or stable sudo xoa-updater upgrade - This can be ran via the UI or this command. Both need to be done twice to do the upgrade and/or downgrade. register needs a free xen-orchestra.com account; see the README. And host connected via proxy. [image: Screenshot_20261009_150011.png]

Hi! We recieved a fix via the support after opening a ticket as suggested. Now the pool metadata backup is running smoothly again. As far as i know 6.9 will become "stable" after 6.10 is released. I'd still suggest a patch for the stable version, unless the new release is a few days. Best wishes Jacob

I tried this on my lab (with XO 6.9.1), moving the pool master to the other host with xe pool-designate-new-master and then back. XO stayed connected both times and picked up the new master, even though Settings > Servers still showed the old host's address; on the way back it took a minute or two to catch up. I didn't test 6.2.2, and I used the CLI rather than the XO 5 Advanced tab, so my guess that your older version is the difference is only a guess. For the XVA, I'm not aware of release notes for the appliance image itself: it updates itself after import, and the notes that exist are per XO version, in the monthly blog post and the changelog, both linked from https://docs.xen-orchestra.com/getting-started/releases#release-cadence-and-channels . How often the downloadable XVA gets rebuilt I don't know, so the 2025.12 tag may just be the date of the base image, but I'd rather ask than guess.

@bug-meister Ah. That's cloud-init's support for templating user-data. The issue is that with these templates you only have access to the info available inside the VM itself. No outside data can be used for templating unless it is somehow passed to the VM (inject a file, set xenstore values...)

This came up in https://xcp-ng.org/forum/topic/11728 last winter, with the same kind of setup, an ISO SR served by a VM on the host. Olivier's answer there was to eject the CDs from the VMs, unplug the ISO SR's PBD, and only then shut the host down, using xe vm-cd-eject --multiple and xe pbd-unplug uuid=<PBD UUID> for the first two steps (the PBD one is in the CLI reference: https://docs.xcp-ng.org/appendix/cli_reference#pbd-unplug). @mickwilli then added the unplug to his UPS shutdown script, and his host shut down cleanly after that. I haven't tried it with an SMB share myself, so I can't promise it behaves like his NFS one, but your NUT script on the Pi looks like the natural place for those two steps, just before the shutdown command.

@hrvojer There are many bugs in older versions of the Xen PV drivers. I suggest running Windows without guest tools and drivers if you can take the performance and functionality hit (no suspend/migration on UEFI VMs, no metric reporting, etc).

Thanks for coming back with that. Commit 8c2f3 is PR #10518 (https://github.com/vatesfr/xen-orchestra/pull/10518), and the changelog lists it under XO 6.9.1 from 5 October, so XOA users get it with 6.9.1, on the latest channel for now if I read the release channels right.

The docs have a section for this symptom, Windows Server 2025 hanging at 0% CPU: https://docs.xcp-ng.org/troubleshooting/windows-pv-tools#windows-server-2025-hangs-randomly-with-0-cpu . Besides the Viridian flags you've already set, it says to revert useplatformclock and useplatformtick with bcdedit if they were ever set in the guest. Your earlier thread showed a VM created from the "Other install media" template, so it's worth checking which template this one came from, since the Windows templates bring their own Viridian settings. I don't think the QEMU SIGTERM is the cause, though: when I force-shut down a VM on a lab host, qemu-dm logged that exact terminating on signal 15 line, sent by xenopsd-xc (ps -o comm -p 1526469 will tell you on yours), so yours most likely just matches your forced shutdown around 10:20 on 5 Oct. If it freezes again after that, the memory dump procedure further down the same page (https://docs.xcp-ng.org/troubleshooting/windows-pv-tools#how-to-gather-kernel-memory-dumps-for-in-depth-troubleshooting) is likely what people who know Windows guests better than me would want to see.

@yannsionneau Hi, I really appreciate the effort, but unfortunately I had to migrate to another hypervisor on this server and it's already away and running. However, when I get a new one I will make sure to test this and report back. Thanks anyway.

So, for everyone who wants to install NUT as a service follow these steps. Modifying the systemd files can make you system unbootable! It should not happen, but there is chance since we are also modifying some "natively shipped files". So an update can break your working configuration again and that is not the fault of XCP-NG!!! As prerequisite it requires the installation and testing of this step-by-step guide https://xcp-ng.org/forum/post/104253. Make sure everything runs before proceeding to the following steps! Now: ################################# Remove "nut-driver.target" dependency ################################# Remove "nut-driver.target" dependency from "nut-server.service" by calling nano /lib/systemd/system/nut-server.service and remove nut-driver.target from routine. I prefer to duplicate and comment to keep the modified rows in the original code. It then should look like this. DO NOT COPY AND PASTE, read, compare and modify carefully! [Unit] Description=Network UPS Tools - power devices information server #After=local-fs.target network.target nut-driver.target After=local-fs.target network.target # We don't Require drivers to be successfully started! This would be # a change of behavior compared to init SysV, and could prevent from # accessing successfully started, at least to audit a system. #Wants=nut-driver.target Wants= # The `upsd` is a networked service (even if bound to a `localhost`) # so it requires that the OS has some notion of networking already. # Extending the unit does not require *this* file to be edited, you # can instead drop in an additional piece of configuration, e.g. add # a `/etc/systemd/system/nut-server.service.d/network.conf` with: # [Unit] # Requires=network-online.target # After=network-online.target Requires=network.target Before=nut-monitor.service PartOf=nut.target [Service] EnvironmentFile=-/etc/ups/nut.conf SyslogIdentifier=%N # Note: foreground mode by default skips writing a PID file (and # needs Type=simple); can use "-FF" here to create one anyway: ExecStart=/usr/sbin/upsd -F ExecReload=/usr/sbin/upsd -c reload -P $MAINPID [Install] WantedBy=nut.target ################################# Add Service for ups-driver ################################# nano /etc/systemd/system/ups-driver.service [Unit] Description=NUT UPS Driver After=network-online.target Wants=network-online.target Before=nut-server.service [Service] Type=oneshot ExecStart=/usr/sbin/upsdrvctl start ExecStop=/usr/sbin/upsdrvctl stop RemainAfterExit=yes [Install] WantedBy=multi-user.target ################################### Add Requirement for nut-server ################################# mkdir -p /etc/systemd/system/nut-server.service.d nano /etc/systemd/system/nut-server.service.d/ups-driver.conf [Unit] Requires=ups-driver.service After=ups-driver.service ################################### Add Requirement for nut monitor ################################# mkdir -p /etc/systemd/system/nut-monitor.service.d nano /etc/systemd/system/nut-monitor.service.d/nut-server.conf [Unit] Requires=nut-server.service After=nut-server.service ################################### Enable services ################################### systemctl daemon-reload systemctl enable ups-driver.service systemctl enable nut.target systemctl enable nut-server.service systemctl enable nut-monitor.service systemctl start nut-monitor.service ################################### Analyze & debugging commands ################################### systemctl list-dependencies nut-monitor.service systemd-analyze critical-chain nut-monitor.service systemctl show nut-monitor.service -p Requires -p Wants -p After systemctl show nut-server.service -p Requires -p Wants -p After

@GregBinSD said: Here are two more notes regarding the XO6 "Unable to connect to XO server. Retry" message, which pops up after 30 seconds. It occurs when either the Chrome or the Microsoft Edge browsers are used on my Windows 11 PC. However, I often use a Samsung Tab-A9 (tablet), and it does not have this issue with XO6. It uses the Chrome browser. To enlighten you the Microsoft Edge your talking about is not the original release (from Windows 10). It’s the Chromium based release from during Windows 10 and has been that one ever since. The original release of Microsoft Edge had its own rendering engine called MSHTML. The current modern Edge effectively shares a common upstream code base with Google Chrome, namely Chromium. The Samsung Tab-A9 doesn’t have the issue even though it, uses the same browser namely Google Chrome. This is the case because the tablet uses a version of Google Android, which has its own kernel, which is a fork or variation of the Linux Kernel.

Update - changes are live in the dev branch now. So figured out the update / switching branches for the proxy by connecting the proxy to my xoa free account. That triggered the available update to next version. From there I found the command that needs to be ran on the proxy to switch back and forth... [image: Screenshot_20261009_143546.png] Latest branch [image: Screenshot_20261009_144414.png] stable branch [image: Screenshot_20261008_202716.png] Backup job ran sucessful. 2026-10-09T17_48_25.447Z - backup NG.txt After the proxy has been deployed... The proxy has been registered with your Xen Orchestra instance. You can manage it from the Xen Orchestra web interface. Next: register the proxy's updater and move it to the 'latest' channel. On the pool master (IP), set a password for the proxy's 'xoa' user (choose your own) and reboot the proxy VM: xe vm-param-set uuid=UUID xenstore-data:vm-data/system-account-xoa-password='<your password>' xe vm-reboot uuid=UUID SSH to the proxy as 'xoa' (IP) and run: sudo xoa-updater register - This registers it with your vates account. sudo xoa-updater configure-channel xo-proxy-appliance-latest - set to latest or stable sudo xoa-updater upgrade - This can be ran via the UI or this command. Both need to be done twice to do the upgrade and/or downgrade. register needs a free xen-orchestra.com account; see the README. And host connected via proxy. [image: Screenshot_20261009_150011.png]

@jp13232 @peek have you tried following this: https://docs.xcp-ng.org/compute/#pci-passthrough ? Also, you can have a look there: https://xcp-ng.org/forum/topic/12523/igpu-pci-passthrough-new-experimental-packages-need-testers if you finally manage to do the passthrough but have "vbios issues" like explained in the thread.

@the_spice @bullerwins @xerxist @hawkpro @vhaelan @ovicz Hi I published a post this morning with packages to test iGPU passthrough, if you have a non production host on which you can test it would be awesome: https://xcp-ng.org/forum/topic/12523/igpu-pci-passthrough-new-experimental-packages-need-testers Thanks! Regards, Yann

@mgr42 Hi I published a post this morning with packages to test, if you have a non production host on which you can test it would be awesome: https://xcp-ng.org/forum/topic/12523/igpu-pci-passthrough-new-experimental-packages-need-testers Thanks! Regards, Yann

@racom.jiristerba Sorry, I missed answering your questions the first time Is the tapdisk QCOW2 commit failure “The device is not writable: Permission denied” a known issue with these package versions on shared LVM/iSCSI storage? Yes, it's a known issue, most of them will be fixed with the latest update, you might need to activate the VDI again but a migration during RPU will be enough Why does rollback attempt to deactivate the active guest LV while tapdisk still holds it open? It's because in the case of VHD, it's the case but with QCOW2 we don't stop the tapdisk process accessing the VDI, it's a change that was missed Is the qcow2OLD_<UUID> naming seen in rollback expected, compared with QCOW2-OLD_<UUID> seen during successful cleanup? It's a pre-existing bug that I already have on my TODO list Is there a supported update, hotfix, or workaround for this configuration? Installing the latest release sm-3.2.12-25.1 during updates (and maybe launching a xe sr-scan uuid=<SR UUI> after updating it so it auto-resolve the undo) should be enough What additional logs are required to identify the original failure of the second QCOW2 VM? I don't think we need any more logs since the errors I'm seeing should already be fixed. If you have any more issues after installing the newest packages, I will take another look What is the recommended recovery procedure without a guest outage, and how should we validate the disk chains before resuming snapshot backups? The sr-scan after updating should do it automatically, it shouldn't need any manipulation. Looking at the storage logs in /var/log/SMlog for any irregularities could help to see problems.

Data point from a 2-host XCP-ng 8.3 pool that supports @tosh's diagnosis, plus a no-patch workaround that gave us ~2.7x until the TCP_NODELAY fix lands. Setup XCP-ng 8.3, xapi-core / vhd-tool 26.1.16-1.2.xcpng8.3, dom0 kernel 4.19.0+1 Two hosts, local ext SRs on NVMe (Samsung 970 EVO Plus / WD Red SN700) Dedicated migration network: 2.5 GbE (Intel i226-V, igc), MTU 9000, no errors Offline storage migration (halted VM, VM.migrate_send) of 2 VDIs (disk + snapshot), 16 GiB virtual / 7773 MiB allocated each; sparse_dd ... -prezeroed ... -dest-proto nbd over TLS Baseline (stock) 132 s per VDI, i.e. ~59 MiB/s on the wire, flat line, same in both directions Link at ~20 % of line rate, source SR read latency 0.3 ms, dom0 total <= 0.5 vCPU, no single dom0 vCPU above 0.08 (RRD, 60 s averages) Sending host with turbo or capped at 2.5 GHz gave the same 132 s, so not CPU-bound here Workaround: disable delayed ACKs on the receiver, only for the migration-network route # on the destination host; adapt prefix/dev/src to the output of: ip route show <migration-net> ip route change 10.10.10.0/24 dev xenbr1 proto kernel scope link src 10.10.10.1 quickack 1 With the receiver ACKing immediately, Nagle on the sender only waits one RTT instead of the ~40 ms delayed-ACK timer. Result (same VM, same direction, same data) stock quickack 1 on receiver per VDI 132 s / 132 s 50 s / 46 s throughput ~59 MiB/s ~155-169 MiB/s whole migration 4:50 2:00 dom0 on the receiver went up to ~1.1 vCPU total, still nothing saturated. Caveats One run per arm, one pool. I did not capture ss -ti during the runs, so the notsent:512 signature is inferred, not observed here. It does not address the reply gating @TeddyAstie described, it only removes the delayed-ACK half. Consistent with that, we land at ~2.7x, below the ~4.3x reported above for TCP_NODELAY (different rig, so not directly comparable). Not persistent: lost on reboot and when xapi re-plugs the PIF. We re-apply it from a small systemd unit at boot as a stopgap and will remove it once vhd-tool ships TCP_NODELAY. Scope is only connections routed via the migration network (storage and live migration). More ACK packets on that link, nothing else changes. Is there a PR or issue for the TCP_NODELAY patch in xapi-project/xen-api that we can follow? I could not find one.