@bleader Thank you for the thorough explanation it greatly helps to understand how the team works to keep these systems secure and functional. From a generalist standpoint, I'll use publicly availability tools to check for and report on any known vulnerabilities within my network (public and private) to me, and then I'll either address those vulnerabilities by either a patch or more commonly a configuration change within a given system. These could include my UPSs or switches, Hypervisors, client devices (laptops etc). Addressing these is a huge portion of the work that I have to address in a day to day, and knowing what would be normal convention to saying "hey I found this issue with a commodity vulnerability scanner, is it going to be addressed" is useful.

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. [image: 1739815845180-6d5087aa-9f38-4c6a-9cbd-c2aef55f5c33-image.png] Some additional screenshots of the mouse instance registry hive values: [image: 1739817060406-16002cf2-1e88-4874-83d4-c769691103c4-image.png] [image: 1739817089195-89518b7c-38bb-4fe1-94e8-d0575eee39b2-image.png] [image: 1739817104459-ae8a2d0e-041a-40cb-bbda-9278aa320c65-image.png]

Running tcpdump switches the interface to promiscuous to allow all traffic that reaches the NIC to be dumped. So I assume the issue you had on your switches allowed traffic to reach the host, that was forwarding it to the VMs, and wasn't dropped because tcpdump switched the VIF into promiscuous mode. If it seems resolved, that's good, otherwise let us know if we need to investigate further on this

@Andrew Ok, thanks I will give that a try.

@olivierlambert Thanks!

@bleader yes, Thank you.

@WillEndure said in Beginner advice - coming from Debian: @DustinB @DustinB said in Beginner advice - coming from Debian: Why are you keen on keeping raw XEN on Debian? Not committed to the idea - its just what I currently have and invested a bit of time into setting it up and understanding it since before XCP-ng was around. Time is a factor too because you can waste a lot of it setting stuff like this up! But overall yes, I should probably move over to XCP-ng for my host. Got it, sunk-cost fallacy.

I think this part of the doc describes your issue: https://docs.xcp-ng.org/releases/release-8-3/#a-uefi-vm-started-once-on-xcp-ng-83-cant-start-if-moved-back-to-xcp-ng-821

@olivierlambert thanks i got it.

Okay weird, at east glad to know it works now

If the machines are on the same pool no problem. If they are not, you need to export the template and import it in the other pool.

Hi, I read it quickly, but it's likely Warm migration is the solution you need.

@olivierlambert got it.

@tjkreidl We don't need performance, but we do need to test how XCP-ng pools, networking, migration, live migration, backup, import from VMware and so on work. It's just a playground where we can have relatively many XCP-ng hosts, but it's not about performance, it's about efficiency and low requirements, because it's just a playground where we learn, validate how things work, and prepare the process for the final migration from VMware to XCP-ng. We originally had two R630s ready for this, then 4, but that would have been unnecessary, given the power consumption, to have physical hypervisors, so in the end we decided to virtualize it all. Well, on ESXi it's because XCP-ng works seamlessly there in nested virtualization.

@WayneSherman Thanks for this.

@spcmediaco FYI, I never figured out how to fix. I am doing backup recovery now.

@Bambos A timeout error means that the host did not reply in the expected delay, which, if I'm remembering correctly is 5 minutes. I suspect a problem on your host but we will take a look further on your support ticket.

@techknowbabble said in GRUB waits for confirmation: What did finally work was re-installing with the 'no serial' option and everything seems to be working as expected now. I only have a handful of XCP-NG installations under my belt but I wonder if this is a known bug or if anyone else has had a similar experience. It's not something I've ever seen before and I've done quite a few installations but I can think of some possibilities as to why something like that might fix the problem. My best guess is that there's something built into, connected to, or otherwise in your system that looks like a serial port (maybe even a real serial port) that spits out a character or two into the system at boot time, confusing GRUB and stopping the normal boot process. The bad KVM I mentioned before was doing something like that, throwing a bogus keypress into the system at boot time.

@plaidypus Ah gotcha, this makes sense. I second scaling out instead of up. If you're getting new hosts, I'd also keep in mind newer CPUs do have much higher per core performance (not sure what your current stuff is), so you also might be able to get away with less vCPUs and lower likelihood of NUMA spanning. Either way though I think scaling out is the better direction to go.