Mouse stops responding in XO console (XCP-ng 8.3, Win11 24H2)
-
FWIW...having the same issue with Server 2025.
-
Just adding a 'me too' to this one - I'm also having this issue (new XCP-ng/XO user). It's very frustrating and seems to be isolated to Windows VMs.
-
Adding dinhngtu in the loop
-
olivierlambert I can't reproduce the problem on demand.... but I still hit it sometimes.
I'm on XCP 8.3 (updates, and test updates), XO source (current master db9c8) and windows (several versions) VM with XS 9.4.0-146 drivers. I have never seen this problem on an XCP 8.2 server. I don't think it's XO or my desktop as I use the same setup to manage all VMs on different hosts.
For me, I don't think it's the host LAN card as the host is fine (different LAN than VM), VM is fine, the video is fine, the keyboard is fine, it's just the XO console mouse that seems to get lost. Restarting the VM fixes the issue. Once I did close the browser window (not the whole browser) and the mouse worked again when I went back to it.
-
I haven't managed to reproduce the problem. For anyone who has this problem, does it persist if you took a snapshot of the affected VM, then restore it from said snapshot?
-
dinhngtu Just restarting the VM is good enough to restore console XO functions.
-
Andrew I meant when the VM is running with the bug present. I'd like to see if there's any way to persist the error state.
-
For what it's worth, my setup is:
- XCP-ng 8.3.0
- XO from sources, master, commit fd9c9
- Windows Server 2012 R2
- XCP-ng Windows Management Agent v8.2.200
I seem to notice the mouse pointer disappearing when moving away from the console window and then coming back (e.g. moving mouse out of the console, changing tab or something like that). Often when I come back, the mouse pointer is nowhere to be seen and I can't get it back.
-
And with XO 6, same issue? (and/or XO Lite)
-
We have a mouse not responding issue with our XCP-ng 8.2,server 2019, and XT 9.4/9.3 If you open device manager is there a USB device with an error? That is how it presents itself for our mouse not responding issue.
-
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:
