XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Mouse stops responding in XO console (XCP-ng 8.3, Win11 24H2)

    Scheduled Pinned Locked Moved XCP-ng
    xcp-ng 8.3windows 11 24h2xo consolexenorchestra
    30 Posts 10 Posters 1.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • olivierlambertO Offline
      olivierlambert Vates 🪐 Co-Founder CEO
      last edited by

      Adding dinhngtu in the loop 🙂

      A 1 Reply Last reply Reply Quote 0
      • A Offline
        Andrew Top contributor @olivierlambert
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • D Offline
          dinhngtu Vates 🪐 XCP-ng Team
          last edited by

          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?

          A 1 Reply Last reply Reply Quote 0
          • A Offline
            Andrew Top contributor @dinhngtu
            last edited by

            dinhngtu Just restarting the VM is good enough to restore console XO functions.

            D 1 Reply Last reply Reply Quote 0
            • D Offline
              dinhngtu Vates 🪐 XCP-ng Team @Andrew
              last edited by

              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.

              A 1 Reply Last reply Reply Quote 0
              • M Offline
                mickwilli
                last edited by

                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.

                1 Reply Last reply Reply Quote 0
                • olivierlambertO Offline
                  olivierlambert Vates 🪐 Co-Founder CEO
                  last edited by

                  And with XO 6, same issue? (and/or XO Lite)

                  1 Reply Last reply Reply Quote 0
                  • N Offline
                    nszmyd
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • M Offline
                      mickwilli
                      last edited by

                      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.

                      remmina_Brinkley - Remote_filemaker.infatech.net.nz:3399_20250102-231359.png
                      remmina_Brinkley - Remote_filemaker.infatech.net.nz:3399_20250102-232020.png remmina_Brinkley - Remote_filemaker.infatech.net.nz:3399_20250102-232100.png

                      D 1 Reply Last reply Reply Quote 1
                      • D Offline
                        dinhngtu Vates 🪐 XCP-ng Team @mickwilli
                        last edited by

                        mickwilli Interesting. It points to a possible issue between QEMU's USB tablet emulation and Windows rather than an issue related to XO.

                        M 1 Reply Last reply Reply Quote 1
                        • M Offline
                          mickwilli @dinhngtu
                          last edited by

                          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.

                          1 Reply Last reply Reply Quote 0
                          • A Offline
                            Andrew Top contributor @dinhngtu
                            last edited by

                            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.

                            1 Reply Last reply Reply Quote 0
                            • M Offline
                              mrchip
                              last edited by mrchip

                              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)

                              D 1 Reply Last reply Reply Quote 0
                              • D Offline
                                dinhngtu Vates 🪐 XCP-ng Team @mrchip
                                last edited by

                                mrchip Could you post a kernel log?

                                M 1 Reply Last reply Reply Quote 0
                                • M Offline
                                  mrchip @dinhngtu
                                  last edited by

                                  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"

                                  D 1 Reply Last reply Reply Quote 0
                                  • D Offline
                                    dinhngtu Vates 🪐 XCP-ng Team @mrchip
                                    last edited by

                                    mrchip Could you post the contents of /var/log/{xensource,daemon}.log on the host (as well as their .1 version) as well? They're pretty big, so you'll have to upload them somewhere.

                                    M 1 Reply Last reply Reply Quote 0
                                    • M Offline
                                      mrchip @dinhngtu
                                      last edited by

                                      dinhngtu sent u a dm with a link to the files

                                      1 Reply Last reply Reply Quote 0
                                      • X Offline
                                        XCP-ng-JustGreat
                                        last edited by

                                        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.

                                        6d5087aa-9f38-4c6a-9cbd-c2aef55f5c33-image.png

                                        Some additional screenshots of the mouse instance registry hive values:

                                        16002cf2-1e88-4874-83d4-c769691103c4-image.png

                                        89518b7c-38bb-4fe1-94e8-d0575eee39b2-image.png

                                        ae8a2d0e-041a-40cb-bbda-9278aa320c65-image.png

                                        M 1 Reply Last reply Reply Quote 2
                                        • D Offline
                                          DevilDan
                                          last edited by DevilDan

                                          Hello, I had freezes of the console, which do not appear any more, I do not know any more exactly what I did on my W11 pro 24H2 new on XCP 8.3 on XOA, I tried at best to :
                                          Disable the VM screen shutdown
                                          Disable standby
                                          Set to maximum performance
                                          The screen is still “active” and not black

                                          But I have another problem, probably related to microsoft, the vm freezes again but completely, inacessible in rdp, console, mouse keyboard, CPU and MEMORY statistics graphs freeze on XOA, restarting the VM by force is mandatory

                                          24H2 has a lot of problems, notably the RDP freeze which also happens to me sometimes, impossible to rdp, sometimes yes sometimes no, I also modified the local strategy concerning this freeze problem but well... We'll see, Microsoft doesn't test its products anymore 😄

                                          EDIT : For RDP Freeze, on the VM, there is a strategy local who fix the bug :

                                          1. Stratégie de l'ordinateur local > Configuration ordinateur > Modèles d'administration > Composants Windows > Services Bureau à distance > Hôte de session Bureau à distance > Connexions > Sélectionner la détection du réseau sur le serveur
                                            --> définir sur Activé
                                            ----->Chosir : Désactiver la détection du temps de connexion et la détection continue du réseau

                                          2. do a : gpupdate /force

                                          3. RDP Works fine now on W11 24H2

                                          M 1 Reply Last reply Reply Quote 1
                                          • M Offline
                                            mickwilli @DevilDan
                                            last edited by

                                            DevilDan this isn't related to the mouse problem, so you are far better to create a new forum post for help with your issue.

                                            D 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post