Mouse stops responding in XO console (XCP-ng 8.3, Win11 24H2)
-
I have done some further testing on this (I have setup a test VM).
What I have learnt:
- The issue occurs irrespective of if the Management Tools/Drivers are installed or not.
- The issue occurs with both Xen Orchestra and XO Lite.
- When the issue occurs, device manager shows that the USB controller is stopped. Uninstalling the device and having Windows reinstall it (scan for hardware changes) is sufficient to get the mouse working again.
-
@mickwilli Interesting. It points to a possible issue between QEMU's USB tablet emulation and Windows rather than an issue related to XO.
-
@dinhngtu well arguably it’s one level up from that as it’s the USB controller that’s getting stopped by Windows, so I’d suggest the issue is the virtual YSB controller.
-
@dinhngtu It happened again to me.... Windows 10 22H2 on XCP 8.2.1...
Same issue as others. Windows reports a USB driver issue. Disabling/re-enabling the windows driver makes it work again.
To answer your question, Yes, reverting to a snapshot with memory keeps the problem of a failed USB/mouse.
-
It's happening to me right now in a debian vm. If I can help let me know what steps you would like me to take. I just noticed my ram has peaked and currently maxing out (8GB)
-
@mrchip Could you post a kernel log?
-
@dinhngtu Hope this is what you r looking for. In the debian machine I did a sudo cat /var/log/kern.log If you need more pls let me know....glad to help (i feel like I can actually do something to help rather than just always ask)
/var/log/kern.log
Jan 26 00:00:10 Server1 kernel: [2365430.803316] audit: type=1400 audit(1737878410.115:54): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=2235578 comm="cups-browsed" capability=23 capname="sys_nice"
Jan 28 00:00:41 Server1 kernel: [2538262.338725] audit: type=1400 audit(1738051241.138:55): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=3011151 comm="cupsd" capability=12 capname="net_admin"
Jan 28 00:00:41 Server1 kernel: [2538262.472961] audit: type=1400 audit(1738051241.270:56): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=3011153 comm="cups-browsed" capability=23 capname="sys_nice"
Jan 29 00:00:06 Server1 kernel: [2624628.082358] audit: type=1400 audit(1738137606.613:57): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=3398507 comm="cupsd" capability=12 capname="net_admin"
Jan 29 00:00:06 Server1 kernel: [2624628.223119] audit: type=1400 audit(1738137606.753:58): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=3398509 comm="cups-browsed" capability=23 capname="sys_nice"
Jan 29 11:04:11 Server1 kernel: [2664473.087788] vethf832f9f: renamed from eth0
Jan 29 11:04:11 Server1 kernel: [2664473.103008] br-edbd4014078c: port 5(veth86cb043) entered disabled state
Jan 29 11:04:11 Server1 kernel: [2664473.183494] br-edbd4014078c: port 5(veth86cb043) entered disabled state
Jan 29 11:04:11 Server1 kernel: [2664473.186667] device veth86cb043 left promiscuous mode
Jan 29 11:04:11 Server1 kernel: [2664473.186681] br-edbd4014078c: port 5(veth86cb043) entered disabled state
Jan 29 11:04:12 Server1 kernel: [2664474.427682] br-edbd4014078c: port 3(vethf4ee1d4) entered disabled state
Jan 29 11:04:12 Server1 kernel: [2664474.427918] veth86a96c5: renamed from eth0
Jan 29 11:04:12 Server1 kernel: [2664474.477396] br-edbd4014078c: port 2(veth39cf04c) entered disabled state
Jan 29 11:04:12 Server1 kernel: [2664474.477874] vethf309b04: renamed from eth0
Jan 29 11:04:13 Server1 kernel: [2664474.545685] br-edbd4014078c: port 3(vethf4ee1d4) entered disabled state
Jan 29 11:04:13 Server1 kernel: [2664474.551561] device vethf4ee1d4 left promiscuous mode
Jan 29 11:04:13 Server1 kernel: [2664474.551576] br-edbd4014078c: port 3(vethf4ee1d4) entered disabled state
Jan 29 11:04:13 Server1 kernel: [2664474.595118] br-edbd4014078c: port 2(veth39cf04c) entered disabled state
Jan 29 11:04:13 Server1 kernel: [2664474.596504] device veth39cf04c left promiscuous mode
Jan 29 11:04:13 Server1 kernel: [2664474.596516] br-edbd4014078c: port 2(veth39cf04c) entered disabled state
Jan 29 11:04:14 Server1 kernel: [2664475.911158] br-edbd4014078c: port 1(veth6b48fa5) entered disabled state
Jan 29 11:04:14 Server1 kernel: [2664475.911674] veth5cbeb55: renamed from eth0
Jan 29 11:04:14 Server1 kernel: [2664475.960704] br-edbd4014078c: port 1(veth6b48fa5) entered disabled state
Jan 29 11:04:14 Server1 kernel: [2664475.966880] device veth6b48fa5 left promiscuous mode
Jan 29 11:04:14 Server1 kernel: [2664475.966895] br-edbd4014078c: port 1(veth6b48fa5) entered disabled state
Jan 29 11:04:22 Server1 kernel: [2664484.107936] br-edbd4014078c: port 4(veth683c2f5) entered disabled state
Jan 29 11:04:22 Server1 kernel: [2664484.108374] vethf5cbea0: renamed from eth0
Jan 29 11:04:22 Server1 kernel: [2664484.157546] br-edbd4014078c: port 4(veth683c2f5) entered disabled state
Jan 29 11:04:22 Server1 kernel: [2664484.160841] device veth683c2f5 left promiscuous mode
Jan 29 11:04:22 Server1 kernel: [2664484.160854] br-edbd4014078c: port 4(veth683c2f5) entered disabled state
Jan 29 11:22:29 Server1 kernel: [2665571.445517] br-edbd4014078c: port 1(veth4aec386) entered blocking state
Jan 29 11:22:29 Server1 kernel: [2665571.445527] br-edbd4014078c: port 1(veth4aec386) entered disabled state
Jan 29 11:22:29 Server1 kernel: [2665571.445770] device veth4aec386 entered promiscuous mode
Jan 29 11:22:29 Server1 kernel: [2665571.505153] br-edbd4014078c: port 2(veth2a255f6) entered blocking state
Jan 29 11:22:29 Server1 kernel: [2665571.505162] br-edbd4014078c: port 2(veth2a255f6) entered disabled state
Jan 29 11:22:29 Server1 kernel: [2665571.505790] device veth2a255f6 entered promiscuous mode
Jan 29 11:22:29 Server1 kernel: [2665571.518601] br-edbd4014078c: port 2(veth2a255f6) entered blocking state
Jan 29 11:22:29 Server1 kernel: [2665571.518609] br-edbd4014078c: port 2(veth2a255f6) entered forwarding state
Jan 29 11:22:29 Server1 kernel: [2665571.518998] br-edbd4014078c: port 2(veth2a255f6) entered disabled state
Jan 29 11:22:29 Server1 kernel: [2665571.552743] br-edbd4014078c: port 3(vethaf13886) entered blocking state
Jan 29 11:22:29 Server1 kernel: [2665571.552752] br-edbd4014078c: port 3(vethaf13886) entered disabled state
Jan 29 11:22:29 Server1 kernel: [2665571.554815] device vethaf13886 entered promiscuous mode
Jan 29 11:22:29 Server1 kernel: [2665571.555131] br-edbd4014078c: port 3(vethaf13886) entered blocking state
Jan 29 11:22:29 Server1 kernel: [2665571.555137] br-edbd4014078c: port 3(vethaf13886) entered forwarding state
Jan 29 11:22:29 Server1 kernel: [2665571.555590] br-edbd4014078c: port 3(vethaf13886) entered disabled state
Jan 29 11:22:30 Server1 kernel: [2665571.606822] br-edbd4014078c: port 4(veth2223bee) entered blocking state
Jan 29 11:22:30 Server1 kernel: [2665571.606831] br-edbd4014078c: port 4(veth2223bee) entered disabled state
Jan 29 11:22:30 Server1 kernel: [2665571.607027] device veth2223bee entered promiscuous mode
Jan 29 11:22:30 Server1 kernel: [2665571.607342] br-edbd4014078c: port 4(veth2223bee) entered blocking state
Jan 29 11:22:30 Server1 kernel: [2665571.607347] br-edbd4014078c: port 4(veth2223bee) entered forwarding state
Jan 29 11:22:30 Server1 kernel: [2665572.455928] br-edbd4014078c: port 4(veth2223bee) entered disabled state
Jan 29 11:22:32 Server1 kernel: [2665573.589693] eth0: renamed from vethf5e03fb
Jan 29 11:22:32 Server1 kernel: [2665573.649374] eth0: renamed from vethf0c6038
Jan 29 11:22:32 Server1 kernel: [2665573.667658] eth0: renamed from veth1995f96
Jan 29 11:22:32 Server1 kernel: [2665573.712825] IPv6: ADDRCONF(NETDEV_CHANGE): veth2223bee: link becomes ready
Jan 29 11:22:32 Server1 kernel: [2665573.713118] br-edbd4014078c: port 4(veth2223bee) entered blocking state
Jan 29 11:22:32 Server1 kernel: [2665573.713124] br-edbd4014078c: port 4(veth2223bee) entered forwarding state
Jan 29 11:22:32 Server1 kernel: [2665573.714903] IPv6: ADDRCONF(NETDEV_CHANGE): vethaf13886: link becomes ready
Jan 29 11:22:32 Server1 kernel: [2665573.715122] br-edbd4014078c: port 3(vethaf13886) entered blocking state
Jan 29 11:22:32 Server1 kernel: [2665573.715129] br-edbd4014078c: port 3(vethaf13886) entered forwarding state
Jan 29 11:22:32 Server1 kernel: [2665573.716337] IPv6: ADDRCONF(NETDEV_CHANGE): veth2a255f6: link becomes ready
Jan 29 11:22:32 Server1 kernel: [2665573.716774] br-edbd4014078c: port 2(veth2a255f6) entered blocking state
Jan 29 11:22:32 Server1 kernel: [2665573.716782] br-edbd4014078c: port 2(veth2a255f6) entered forwarding state
Jan 29 11:22:32 Server1 kernel: [2665573.717541] eth0: renamed from veth558de09
Jan 29 11:22:32 Server1 kernel: [2665573.741959] IPv6: ADDRCONF(NETDEV_CHANGE): veth4aec386: link becomes ready
Jan 29 11:22:32 Server1 kernel: [2665573.742249] br-edbd4014078c: port 1(veth4aec386) entered blocking state
Jan 29 11:22:32 Server1 kernel: [2665573.742260] br-edbd4014078c: port 1(veth4aec386) entered forwarding state
Jan 29 11:22:32 Server1 kernel: [2665574.169423] br-edbd4014078c: port 5(vethffa23f9) entered blocking state
Jan 29 11:22:32 Server1 kernel: [2665574.169432] br-edbd4014078c: port 5(vethffa23f9) entered disabled state
Jan 29 11:22:32 Server1 kernel: [2665574.173953] device vethffa23f9 entered promiscuous mode
Jan 29 11:22:32 Server1 kernel: [2665574.174386] br-edbd4014078c: port 5(vethffa23f9) entered blocking state
Jan 29 11:22:32 Server1 kernel: [2665574.174392] br-edbd4014078c: port 5(vethffa23f9) entered forwarding state
Jan 29 11:22:32 Server1 kernel: [2665574.502871] br-edbd4014078c: port 5(vethffa23f9) entered disabled state
Jan 29 11:22:33 Server1 kernel: [2665575.448654] eth0: renamed from veth45947d1
Jan 29 11:22:33 Server1 kernel: [2665575.479261] IPv6: ADDRCONF(NETDEV_CHANGE): vethffa23f9: link becomes ready
Jan 29 11:22:33 Server1 kernel: [2665575.479584] br-edbd4014078c: port 5(vethffa23f9) entered blocking state
Jan 29 11:22:33 Server1 kernel: [2665575.479591] br-edbd4014078c: port 5(vethffa23f9) entered forwarding state
Jan 29 22:26:04 Server1 kernel: [2705386.167132] uhci_hcd 0000:00:01.2: host controller halted, very bad!
Jan 29 22:26:04 Server1 kernel: [2705386.168306] uhci_hcd 0000:00:01.2: HC died; cleaning up
Jan 29 22:26:04 Server1 kernel: [2705386.168843] usb 1-2: USB disconnect, device number 2
Jan 30 00:00:35 Server1 kernel: [2711057.357727] audit: type=1400 audit(1738224035.619:59): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=4011142 comm="cupsd" capability=12 capname="net_admin"
Jan 30 00:00:35 Server1 kernel: [2711057.537107] audit: type=1400 audit(1738224035.795:60): apparmor="DENIED" operation="capable" profile="/usr/sbin/cups-browsed" pid=4011144 comm="cups-browsed" capability=23 capname="sys_nice" -
@mrchip Could you post the contents of
/var/log/{xensource,daemon}.logon the host (as well as their.1version) as well? They're pretty big, so you'll have to upload them somewhere. -
@dinhngtu sent u a dm with a link to the files
-
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:
