Mouse stops responding in XO console (XCP-ng 8.3, Win11 24H2)
-
Testing:
- XCP-ng v8.3 (fresh install from downloaded ISO and fully updated)
- Xen Orchestra (installed and built from git (2024-Nov-18 9939cee)
- Guest VM - Windows 11 Pro 24H2 (fresh install from downloaded ISO and fully updated)
(tested without guest tools and with XenTools 9.40 with the same behavior)
In the XO console, the guests mouse stops responding after some random amount of time (e.g. 5 min or 20 min). When this happens, the keyboard still works in the XO console and the VM is still responsive. The mouse still works when remote controlling the VM via remote support client (and I can see it move in the console when controlling it this way). Rebooting the XO server does not fix it, Restarting the XCP-ng toolstack does not fix it. Rebooting Windows does fix it until it happens again at some random interval.
-
@WayneSherman said in Mouse stops responding in XO console (XCP-ng 8.3, Win11 24H2):
In the XO console, the guests mouse stops responding after some random amount of time (e.g. 5 min or 20 min).
The mouse freezing was becoming more frequent and happening sooner after a VM reboot (sometimes seconds after I start using the web UI console, or within a minute or two).
So I shutdown and rebooted the XCP-ng host computer and the mouse freezing does not appear to happen quickly now (hasn't happened yet). I hypothesize that the longer the host computer is running the faster and more frequent this problem happens.
-
@WayneSherman I have Windows running on XCP 8.3 with XT 9.4 and things have been fine. Also I have not seen this issue (ever) on my 8.2 hosts.
I have seen this mouse issue on a different XCP 8.3 test machine with windows guests (Win10 and Server 2022). It seemed to happen when I made network changes on the host for the guest. I thought the guest locked up but it was just the mouse (KB still worked). I did not do any additional testing then, but I can leave it running for a while and see what happens.
I don't see this as an XO problem as I use the same XO for other hosts/guests that don't have a problem.
-
@Andrew said in Mouse stops responding in XO console (XCP-ng 8.3, Win11 24H2):
I don't see this as an XO problem as I use the same XO for other hosts/guests that don't have a problem.
I agree, I don't think it is an XO problem. When the mouse stopped working I rebooted XO but the mouse was still broke. I restarted the toolstack on XCP-ng and it was still broke. I think XO is sending mouse events but the Windows VM has stopped receiving or responding to them.
(also, the problem doesn't happen on the Debian 12 VM installed on the same host)
-
I have been investigating a network hardware offload issue with the Realtek RTL8125BG 2.5G on the same XCP-ng host computer. This separate issue was resolved by shutting off TX checksum offload on the physical interface.
It made me think that maybe the mouse problem is caused by something similar on the other NIC. The second NIC in the computer is Realtek R8111EPV (1G)(using Linux r8169 driver) which is the one I have been using when I noticed the mouse issue. So I ran a capture test on the XCP-ng host:
tcpdump -i eth1 -v -nn | grep incorrect
and found bad packet checksums on some of the received packets coming in to the Windows VM:
x.x.x.x.443 > [windows.vm.ip].49715: Flags [P.], cksum 0xc656 (incorrect -> 0xb854), seq 1:2433, ack 216, win 2052, length 2432 x.x.x.x.443 > [windows.vm.ip].49717: Flags [P.], cksum 0x2e6c (incorrect -> 0xcff2), seq 1:2921, ack 218, win 501, length 2920 x.x.x.x.443 > [windows.vm.ip].49720: Flags [.], cksum 0x1b11 (incorrect -> 0xb99c), seq 1:2921, ack 213, win 16384, length 2920 ...
Running this on the XCP-ng host stopped the checksum errors:
ethtool -K eth1 gro off # testing only, not persistent
Making this setting persistent:
xe pif-param-set uuid=my_eth1_PIF_UUID other-config:ethtool-gro="off"
After making this change I will monitor the VM to see if the mouse problem returns.
-
@WayneSherman said in Mouse stops responding in XO console (XCP-ng 8.3, Win11 24H2):
It made me think that maybe the mouse problem is caused by something similar on the other NIC. The second NIC in the computer is Realtek R8111EPV (1G)(using Linux r8169 driver) which is the one I have been using when I noticed the mouse issue. So I ran a capture test ... and found bad packet checksums on some of the received packets coming in to the Windows VM
I cannot confirm that the network errors were related to the issue of the mouse freezing. After running all weekend (on eth1, with gro offloading set to on, and network packet errors present) I have not been able to replicate the mouse freezing.
-
FWIW...having the same issue with Server 2025.