Tools: Windows 11 in Virt-Manager on Ubuntu, Why I Switched from UEFI to BIOS - 2025 Update
The gotcha
What finally worked
The Windows 11 bypass
SPICE clipboard sharing
Shared folders with virtiofs
The main lesson Setting up a Windows 11 VM in Virt-Manager on Ubuntu sounds easy enough until you discover: · clipboard sharing does not work
· shared folders do not mount· the SPICE guest agent crashes over and over I burned a lot more time on this than I should have, and the problem turned out not to be one more missing guest tool. It was the firmware choice. Virt-Manager wants to use UEFI for Windows 11 by default, which makes sense on paper because Windows 11 expects TPM and Secure Boot. In practice, for this setup, UEFI was the thing that broke integration for me. The fix was to rebuild the VM as a BIOS-based VM, then bypass the Windows 11 TPM and Secure Boot checks during setup. Once I did that, clipboard sharing and shared folders started behaving normally after the rest of the pieces were installed in the right order. Here is the working order: That order mattered a lot more than I expected. If you install on a BIOS VM, Windows 11 will complain about unsupported hardware. At the first setup screen: · Press Shift + F10· Run regedit· Go to HKEY_LOCAL_MACHINE\SYSTEM\Setup· Create a key named LabConfig· Inside it, create these DWORD values and set each to 1:BypassTPMCheckBypassSecureBootCheckBypassRAMCheck After that, installation continues normally. Once Windows 11 is installed, install the SPICE guest tools and reboot. Then check whether vdservice is running in an elevated PowerShell window: Get-Service | Where-Object {$_.DisplayName -match "spice|vdagent"} If needed:Start-Service -Name "vdservice"Set-Service -Name "vdservice" -StartupType Automatic If your clipboard still does not work and vdservice keeps crashing in a loop, check the firmware choice first. In my case, UEFI was the real issue. Shared folders took a few moving parts: · host-side shared memory config· virtiofs hardware added to the VM· VirtIO guest tools in Windows· WinFSP installed in Windows· VirtioFsSvc switched to Automatic On the host, I also had to add this block to the VM XML after the Then I added a Filesystem device in Virt-Manager using: · Driver:virtiofs· Source path: your shared folder· Target path: a mount tag like vmshare Inside the Windows VM, after installing VirtIO guest tools and WinFSP, I checked services again: Get-Service | Where-Object {$_.DisplayName -match "virtio|winfsp|virtiofs"} And then forced the VirtIO FS service to persist across reboots: Start-Service -Name "VirtioFsSvc"Set-Service -Name "VirtioFsSvc" -StartupType Automatic That last step matters. If you skip it, the share may disappear again after reboot. The biggest trap here was assuming the default UEFI path was the correct path just because Windows 11 prefers it.For me, that was exactly what caused the clipboard and shared-folder headaches. Once I rebuilt the VM using BIOS, then installed everything in the right order, the setup became stable. I put the full write-up here, including the exact XML edit, the install order, and the troubleshooting notes:How to Set Up a Windows 11 VM in Virt-Manager on Ubuntu Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or - Create the VM in Virt-Manager- Before installation, switch firmware from UEFI to BIOS- Install Windows 11 using the usual LabConfig registry bypass- Install SPICE guest tools- Confirm vdservice is running- Add the memoryBacking block to the VM XML- Add a shared filesystem using virtiofs- Install VirtIO guest tools in the Windows VM- Install WinFSP- Set VirtioFsSvc to Automatic