@jiri.hadamek Yes, it's a driver bug. I'll plan for a fix.

If the host is really old I'd also check Windows 11 version 24H2 supported Intel processors

@markr I did a test install with en-us_windows_11_business_editions_version_24h2_updated_july_2025_x64_dvd_d32522f0.iso which went to OOBE with no issues. If you have a new Intel CPU, does doing https://docs.xcp-ng.org/troubleshooting/windows-pv-tools/#windows-bug-check-0x3b-system_service_exception-on-systems-with-newer-intel-cpus help?

@jiri.hadamek The drivers don't like that value being a REG_QWORD. Try using REG_DWORD instead.

@deefdragon Your XAPI is also lagging behind (25.6.0-1.5 vs latest 25.6.0-1.9). Could you update your pool?

@deefdragon How about host Xen and XAPI versions? I'm on the bleeding edge, so this may have been fixed somewhere already.

# unbuffer yum list installed | grep xen\\\|xapi
mellanox-mlnxen.x86_64            5.9_0.5.5.0-2.1.xcpng8.3    @xcp:main/$releasever
python2-xapi-storage.x86_64       24.19.2-1.10.xcpng8.3       @xcp-ng-testing
xapi-core.x86_64                  25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xapi-nbd.x86_64                   25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xapi-rrd2csv.x86_64               25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xapi-storage-script.x86_64        25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xapi-tests.x86_64                 25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xapi-xe.x86_64                    25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xcp-ng-xapi-plugins.noarch        1.12.0-1.xcpng8.3           @xcp-ng-testing
xen-crashdump-analyser.x86_64     2.6.1-1.xcpng8.3            @xcp:main/$releasever
xen-dom0-libs.x86_64              4.17.5-15.2.xcpng8.3        @xcp-ng-incoming
xen-dom0-tools.x86_64             4.17.5-15.2.xcpng8.3        @xcp-ng-incoming
xen-hypervisor.x86_64             4.17.5-15.2.xcpng8.3        @xcp-ng-incoming
xen-libs.x86_64                   4.17.5-15.2.xcpng8.3        @xcp-ng-incoming
xen-tools.x86_64                  4.17.5-15.2.xcpng8.3        @xcp-ng-incoming
xengt-userspace.noarch            4.0.0-1.xcpng8.3            @xcp:main/$releasever
xenopsd.x86_64                    25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xenopsd-cli.x86_64                25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xenopsd-xc.x86_64                 25.6.0-1.10.xcpng8.3        @xcp-ng-incoming
xenserver-dracut.noarch           10-2.xcpng8.3               @xcp:main/$releasever
xenserver-hwdata.noarch           20240411-1.xcpng8.3         @xcp:main/$releasever
xenserver-status-report.noarch    2.0.11-1.xcpng8.3           @xcp-ng-ci

@deefdragon All three values match for me with XCP-ng 8.3, Ubuntu 24.04 guests and kernel 6.8:

$ sudo cat /sys/devices/virtual/dmi/id/product_serial
adc9b6ba-d187-0844-13a6-5f1dc155bf6e
$ sudo cat /sys/devices/virtual/dmi/id/product_uuid
adc9b6ba-d187-0844-13a6-5f1dc155bf6e
$ sudo cat /sys/hypervisor/uuid
adc9b6ba-d187-0844-13a6-5f1dc155bf6e

From your Github issue, it looks like a confusion in byte order between the System UUID (6a87cb0f-ca4c-ffa5-3ca2-fc398fb25eac) and the XCP-ng VM UUID (0fcb876a-4cca-a5ff-3ca2-fc398fb25eac).

I'd check the guest kernel version first.

@flakpyro It's most likely a bug in the Citrix agent.

@McHenry Yes, that's the cause of your issue.

@McHenry That's your Dom0 partition, which stores the XCP-ng operating system. Don't store the ISOs there (which your local ISO SR is doing), you should mount an ISO SR using NFS instead.

/var/log shouldn't be an issue as it's in a separate partition. (I misread the df output)

@McHenry /dev/md127p1 (the root partition) looks pretty full. Do you store anything big in there (ISOs...)?

@McHenry Do they work if you turn off Secure Boot? There's a procedure to enable Secure Boot, see https://docs.xcp-ng.org/guides/guest-UEFI-Secure-Boot/ .

Do you have space left on your Dom0 disk?

@McHenry Do you have any relevant host logs in /var/log/xensource.log and /var/log/daemon.log (look for xen_platform_log)?

Updated with working procedure. (tl;dr XenClean should fix this)

@bberndt Okay, I managed to reproduce your situation. I think it's because the "driver via Windows Update" option was enabled after installing the XS drivers, which caused the drivers to lock onto the non-C000 device and prevent updates from coming in.

Normally, XenClean should be able to fix the situation. But if you want to fix things manually, or if things still don't work (C000 is still not active), here's a procedure that should fix the problem:

1. Take a snapshot/backup/etc.
2. Keep a note of static IP addresses (if you have any; there's a chance those will be lost). You can also use our script here: https://github.com/xcp-ng/win-pv-drivers/blob/xcp-ng-9.1/XenDriverUtils/Copy-XenVifSettings.ps1
3. Reboot in safe mode and disable the non-C000 device.
4. Reboot back to normal mode; it'll ask you to reboot a few more times.
5. The C000 device should now be active and you should be able to get driver updates again.
6. (Optional) You can now enable and manually update the non-C000 device (Browse my computer - Let me pick).

@bberndt That's really odd. What does Update Driver say? I'll try to ask the XS driver maintainer about it.

@dnikola Here are our driver recommendations:

• For non-prod environments (homelab, test VMs, whenever possible): use the new XCP-ng drivers in testsign mode. We'd really appreciate having people to test the driver/guest agent and provide us with feedback.
• For prod environments: use XenServer drivers. (9.4.1 or later to avoid the recent vulnerability)

@bberndt It's normal to have 2 PV Bus devices if you have the "driver via Windows Update" VM option enabled, but I don't expect them to have different driver versions. Is the C000 device the active one? (you can see with View - Devices by connection) Maybe the non-C000 device didn't get the update due to it not having an update-tagged device ID.

@bberndt said in Migrating from XCP-ng Windows guest tools to Citrix:

XenServer PV Bus 9.19.105 (old)

Could you confirm which driver/device this was? It didn't look right.
Also, are you pulling updates through WSUS or something similar? Normally Windows should be able to update all the PV drivers on its own.

Otherwise, in a fresh Windows installation the drivers gotten from Windows Update are as following:

• Bus 9.1.11.115
• Interface 9.1.12.94
• Network Class 9.1.13.107
• Network Device 9.1.7.65 (old, but normal; there's been no updates to this driver since)
• Storage 9.1.9.82

Rolling back to older drivers then running Windows Update got me the newest drivers as expected.

@bberndt Things sound OK to me. Are you looking for an update procedure?

With Windows Update, some drivers won't be installed automatically but will be available in Optional updates instead.