Latest test updates were applied to three-node home lab pool (3 x Dell OptiPlex SFF 7040 i7-6700/48GB RAM/256GB NVMe boot drive/TrueNAS Core 10Gbps-attached NFS shared storage) without incident. VMs appear to running normally, live migration between hosts works fine and no apparent problems so far.

Hi All. Yes, this is a very annoying problem that I've also experienced after a fresh Windows 11-24H2 install on XCP-ng 8.3 fully production-patched to date. I am accessing my Windows 11 VM console via a Windows 11-24H2 physical client PC using latest Firefox browser. The keyboard and mouse attached to my laptop via a Dell DisplayLink D3100 USB3 dock are a standard wired Logitech mouse with scroll and a wired Logitech keyboard. The XCP-ng 8.3 host is managed via XO from source (XOS) on the latest commit (66e67) as of yesterday 2/16/2025. XOS lives in an AlmaLinux 8.10 VM built with @ronivay 's superb installation script.

After some Googling around, this frozen mouse issue appears to have occurred in other hypervisors too. It looks to be a Windows problem rather than an XCP-ng 8.3/XO/QEMU problem. (I see you smiling @olivierlambert ).

I can't guarantee this technique will work for everyone, but after a day, I am no longer experiencing the mouse failure.

What appears to be happening is that the Windows Plug-and-Play (PNP) mouse driver configuration is getting borked due to multiple triggerings of PNP. During the first-boot of the VM post-installation, it finds the original emulated hardware. Following the installation of the Citrix management agent 9.4, it performs additional device configuration that doesn't always go well. In the device manager, click view, show hidden devices to see any phantom devices that I generally remove so as to keep everything as clean and pristine as possible.

This Windows registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class{4D36E96F-E325-11CE-BFC1-08002BE10318} is your friend.

You must make sure that the value mouclass is the only value in the UpperFilters key of the above device class hive. As a general preventative against Windows oddities, I changed the value and then changed it back to mouclass to force the registry editor to rewrite the hive. You should also delete the mouse instance details folders 0000, 0001 etc. These should get deleted for you when you remove the mouse devices from the device manager. Windows will recreate those during the reboot.

Random aside: another thing I like to do is to change the VM's UEFI OVMF display settings to 1280x960 in the Tiano UEFI firmware. This allows me to see the entire VM on my 1920x1080 HD monitor when Firefox is in full-screen mode, XO console scale set to 100%, and the Windows VM display resolution also set to 1280x960. This is intended to prevent weird visual scaling anomalies.

The following image is my device manager after the fix. When the mouse was malfunctioning, the system had only created the PS/2 mouse device. The HID-compliant mouse was created after deleting the original PS/2 mouse device and the failed USB Universal Host Controller devices in device manager. Following this, scan for new devices to recreate what is missing and reboot the VM so that those devices get registered and initialized correctly.

Some additional screenshots of the mouse instance registry hive values:

Applied latest candidate test updates to 3 x Dell OptiPlex 7040 (i7-6700, 48GB, 10Gbps-attached TrueNAS shared-storage) pool. Update process was error-free and successful. Everything appears to be working normally following the update.

Latest version 8.3 candidate updates installed and are working fine on three-host home lab pool. Received a couple of repo errors for a certain mirror, but yum tried another mirror and it completed successfully. After updates were applied, performed live migrations between hosts with no problems and updated a Windows 11 Version 24H2 VM to the November 2024 cumulative update without problems. (VM is currently running Citrix Tools 9.3.2 without issues.)

Applying the latest XCP-ng 8.3 RC2 "xen-*" and intel-microcode updates from the candidate repository worked great here as well. Everything appears to be running well.

Latest updates over ISO-installed 8.3 RC2 worked fine for me. I did experience one host in my three-host pool to which no VMs could be migrated. After looking at the networking from bash in DOM0, it showed that both 10G ports for the storage and migration networks were DOWN. These ports are on a genuine IBM-branded Intel X540-T2 card I bought used on eBay so it might have gone bad. Since the card has worked well for some time, I figured it couldn't hurt to re-seat it in the PCIe slot. Sure enough, that fixed it. Moral of the story: check the mundane stuff first; it's not always the fault of new updates.

Upgraded 3-node pool (home lab: Dell OptiPlex 7040 SFF x 3) from 8.3 RC1 to 8.3 RC2 using bootable ISO. It worked perfectly for me. As others have noted, it does ask you to select the management interface when upgrading the slave nodes. Once you do that, it automatically populates all of the previously configured network parameters for that host so you are really only confirming the existing values. The OptiPlex 7040's (i7-6700) all have Intel VPro AMT so they are running headless. The MeshCommander program is used to access the VPro console on each host. A DisplayPort display emulator dongle is needed to keep the integrated-GPU active in order to be able to see the console and firmware setup screens with this configuration. It's effectively a poor man's iDRAC. So far, everything is working well on 8.3 RC2.

Serious movement appears to be happening with respect to NV. See videos below cross-posted from this forum thread:

https://xcp-ng.org/forum/topic/8932/hardware-assisted-virtualization-is-not-enabled-on-this-host-even-though-platform-exp-nested-hvm-true-is-set/52

Nested Virtualization (X86) Part I - George Dunlap, Xen Server:
https://www.youtube.com/watch?v=8jKGYY1Bi_o

Nested Virtualization (X86) Part II - George Dunlap, Xen Server:
https://www.youtube.com/watch?v=3MxWvVTmY1s

@abudef Thank you for providing these links to George Dunlap's Xen Summit nested virtualization talk. It was very informative and also demonstrates a strong commitment to bringing NV to Xen Hypervisor and its derivatives. Particularly in light of Broadcom's acquisition of VMware and the resulting customer exodus, adopting XCP-ng and Vates looks to be an increasingly smart play. I will cross-post the provided links to the big NV thread on here.

Applied recent 87 updates to 3-node home-lab pool running XCP-ng 8.3 using XO from source on the latest commit. The update worked perfectly and a mix of existing Linux and Windows VMs are running normally after the update.

@doogie06 Thank you too! I also have XO setup for self-signed TLS access. I knew about the xo-cli task deletion command, but always had to disable TLS in my /root/.config/xo-server/config.toml file and then restart xo-server.service to delete the orphaned tasks. The allowUnauthorized parameter was just what I needed. That's why this community is really wonderful. Thanks again.

@julien-f @olivierlambert I've said it before and I'll say it again: "Wow, that was fast!" You guys do more to foster international cooperation than most of our planet's governments. Keep up the great work. Thank you Vates for creating, maintaining and improving this fantastic software!

@Andrew Sorry, I should have added that it remains broken in the latest master commit 8b7e1.

Using XO from source code. Commit bfb8d3b29e4f9531dda368f6624652479682b69d dated 12 March 2024 @ 11:22:12 broke it. Commit immediately before that 51f95b3c8590492164be38a77ad2c7bf5dc42451 dated 12 March 2024 @ 11:18:20 exporting VM works. Seems to be something related to undici code.

@ajpri1998 Don't despair. Also, don't go crazy trying to make the processor look like a newer one in order to be acceptable to Windows 11. The registry bypasses work. I am personally running an Intel Haswell era laptop: UEFI secure boot, but no TPM, i7-4700HQ, 16GB RAM; it runs Windows 11 Pro perfectly. Believe me, as a long time Microsoft user and enterprise customer, if Satya Nadella didn't want your old box to run Windows 11, it wouldn't. Microsoft provides this workaround so technical users can run the latest Windows until THEY are ready to upgrade to new hardware. My home computing lab is 3 x Dell OptiPlex 7040 SFF eBay used bargains (i7-6700 CPUs) running XCP-ng 8.3 with Xen Kernel 4.17 and a diverse mix of Linux and Windows VMs including Windows 11. It's an evolution to a more secure computing future. We're all on the journey at our own pace. Relax and enjoy it. Use the hardware you have. It's "new enough."

Stats are back in XO after latest XCP-ng 8.3 updates and compiling XO from latest source. That was fast!

@john-c @stormi @olivierlambert All, given the complexities involved in providing an automated solution for this issue, it may make the most sense at this time to mitigate any negative outcomes using an installation/update warning. For instance, throw a message dialog issued by both the ISO installer and the pool update feature in XO such as: WARNING: One or more of the pending updates may alter your VM's firmware. If you are using Microsoft BitLocker to encrypt virtual drives, you should exit now and suspend BitLocker prior to performing this update. (Provide customer with Exit or Continue buttons with Exit selected by default.)

Re: XCP-ng 8.3 beta

Had a couple of Windows 11 VMs setup previously on XCP-ng Beta 8.3 with UEFI Secure Boot, vTPM and BitLocker encryption active. After applying the latest updates, unencrypted UEFI Secure Boot Windows VMs still boot fine, but BitLocker encrypted Windows VMs boot to blue screen and prompt for the BitLocker recovery key. Normally with Windows, an OEM firmware update will trigger this behavior if BitLocker is not suspended prior to flashing the system firmware. As a result, OEM firmware installers generally check for active encryption and suspend it automatically prior to flashing the firmware. Not sure which of the latest updates changed the VM firmware state values, but this could potentially be a huge issue for a production system. In my case, these were just test VMs so no damage was incurred.

@olivierlambert You and the rest of the Vates team are already my Xen heros! I've been running XCP-ng 8.3 Beta on my home lab since August. I was impressed to see the new virtual TPM option in XO this weekend after pulling and compiling the latest source code. (BTW: Windows 11-23H2 BitLocker works flawlessly with the new vTPM support.) XCP-ng and XO truly just keep getting better and better! Hopefully, nested-virtualization of Windows Hyper-V on Xen will get solved before too long since a good variety of capable hypervisor options is important for a healthy and competitive virtualization ecosystem. This is especially true now as we all look to see what Broadcom will do as the new owner of VMware.