Setting Up a Windows 11 VM on Proxmox with VirtIO

Windows 11 on Proxmox is one of the most common setups I get asked about, and for good reason. Whether it's for GPU passthrough gaming, running Windows-only software, or testing Active Directory configurations, Proxmox handles Windows guests well — once you get the initial setup right.

The catch is that Windows 11 added hardware requirements that make VM installation trickier than it used to be. TPM 2.0, Secure Boot, and the minimum spec checks mean you can't just boot the ISO and click through. On top of that, Windows doesn't ship with VirtIO drivers, so your disks and network won't be visible during installation unless you load them manually.

I've refined this process across probably 50+ Windows 11 VMs at this point. Here's the setup that works reliably.

What You'll Need

Before touching Proxmox, download these:

Windows 11 ISO — Grab it from Microsoft's official download page. You want the multi-edition ISO, not the Media Creation Tool version. As of writing, the current build is 24H2 (Build 26100). Upload it to your Proxmox ISO storage, typically at /var/lib/vz/template/iso/.

VirtIO Drivers ISO — Download virtio-win.iso from the Fedora project:

cd /var/lib/vz/template/iso/
wget https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso

As of this writing, virtio-win-0.1.262 is the latest stable release. Don't skip this — without these drivers, your VM won't see its disk during Windows setup.

Creating the VM

Basic Settings

In the Proxmox web UI, click "Create VM" and configure each tab:

General:

VM ID: pick something logical (I use 200+ for Windows VMs)
Name: win11-desktop or whatever suits your naming scheme

OS:

ISO image: select your Windows 11 ISO
Type: Microsoft Windows
Version: 11/2022/2025

System — this is where most people go wrong:

Machine: q35 (not i440fx)
BIOS: OVMF (UEFI)
Add EFI Disk: checked, store on your primary storage
SCSI Controller: VirtIO SCSI single
Add TPM: checked, version v2.0, store on your primary storage
Pre-Enroll keys: checked (this enables Secure Boot)

The q35 machine type is essential for modern Windows features and PCIe passthrough. The i440fx type works but you'll hit limitations later.

Disks:

Bus/Device: SCSI (not IDE, not SATA)
Storage: your preferred pool
Size: 64 GB minimum, I'd recommend 120 GB for a desktop VM
Cache: Write back (better performance, relies on your storage having a battery-backed cache or you accepting the risk)
Discard: checked (enables TRIM — important for SSDs and thin-provisioned storage)
IO Thread: checked
SSD emulation: checked if your backing storage is SSD

CPU:

Sockets: 1
Cores: 4 minimum, 6-8 for a responsive desktop experience
Type: host (critical for performance — don't use the default kvm64)

Memory:

8192 MB minimum. 16384 MB recommended for desktop use.
Ballooning: leave enabled for now, we'll discuss this later

Network:

Model: VirtIO (paravirtualized)
Bridge: vmbr0 (or your preferred bridge)

Adding the VirtIO Drivers ISO

Before starting the VM, add a second CD-ROM drive with the VirtIO drivers:

Hardware > Add > CD/DVD Drive > select virtio-win.iso, use IDE bus (IDE 0 should be your Windows ISO, use IDE 3 or whatever's free).

Your hardware list should now show two ISO images mounted.

Installing Windows 11

Start the VM and open the noVNC console. You'll see the OVMF/UEFI boot screen, then "Press any key to boot from CD or DVD..." — press a key quickly, it times out fast.

Loading VirtIO Drivers During Setup

Windows Setup will start normally. Select your language and click through until you hit "Where do you want to install Windows?" — and you'll see an empty drive list. No disks found.

Click "Load driver" and browse to the VirtIO ISO:

Navigate to D:\vioscsi\w11\amd64 (or wherever the VirtIO ISO mounted)
Select the Red Hat VirtIO SCSI controller driver
Click Next — your SCSI disk should now appear

While you're at it, load the network driver too. Go back to "Load driver":

Navigate to D:\NetKVM\w11\amd64
Select the Red Hat VirtIO Ethernet Adapter driver

Now your disk is visible and you'll have network during setup (useful for the OOBE phase if you want to use a Microsoft account — or not, which I'll cover).

Select your disk and continue with the installation.

The TPM Requirement

Because we added a virtual TPM 2.0 device when creating the VM, Windows 11 should pass its hardware checks without issue. If you forgot the TPM, you'll get the "This PC can't run Windows 11" error.

If you're in that situation and don't want to recreate the VM, you can add the TPM after the fact:

qm set 200 -tpmstate0 local-zfs:1,version=v2.0

Bypassing Requirements (If Needed)

For some edge cases — maybe you're running an older Proxmox version that doesn't support TPM emulation, or you want to skip the Microsoft account requirement — there's the registry trick during setup.

When you hit a screen that blocks you, press Shift+F10 to open a command prompt, then:

reg add HKLM\SYSTEM\Setup\LabConfig /v BypassTPMCheck /t REG_DWORD /d 1
reg add HKLM\SYSTEM\Setup\LabConfig /v BypassSecureBootCheck /t REG_DWORD /d 1
reg add HKLM\SYSTEM\Setup\LabConfig /v BypassRAMCheck /t REG_DWORD /d 1

For bypassing the Microsoft account requirement during OOBE, at the "Let's connect you to a network" screen:

oobe\bypassnro

The system will reboot and give you an "I don't have internet" option. I use this on every Windows VM because I don't want my lab VMs tied to a Microsoft account.

Post-Installation Setup

Installing VirtIO Guest Tools

Once Windows is up and running, open File Explorer and navigate to the VirtIO ISO drive. Run virtio-win-guest-tools.exe — this is the all-in-one installer that includes:

VirtIO Balloon driver (memory ballooning)
VirtIO Serial driver (communication with host)
QEMU Guest Agent
VirtIO Network driver (if you didn't load it during install)
SPICE agent (clipboard sharing, resolution adjustment)

Run it, click through, and reboot when prompted.

Verify the drivers installed correctly by checking Device Manager. You should see no yellow warning triangles. Key devices to verify:

Red Hat VirtIO SCSI controller under Storage controllers
Red Hat VirtIO Ethernet Adapter under Network adapters
VirtIO Balloon Driver under System devices

Enabling QEMU Guest Agent

The guest agent lets Proxmox communicate with the Windows VM for clean shutdowns, filesystem freeze for backups, and IP address reporting.

After installing VirtIO guest tools, the QEMU Guest Agent service should be running. Verify in PowerShell:

Get-Service QEMU-GA

Status   Name               DisplayName
------   ----               -----------
Running  QEMU-GA            QEMU Guest Agent

On the Proxmox side, enable it in the VM options:

qm set 200 -agent enabled=1,fstrim_cloned_disks=1

Or through the web UI: Options > QEMU Guest Agent > Enable.

The fstrim_cloned_disks=1 flag automatically runs fstrim after cloning or moving the disk, which reclaims space on thin-provisioned storage.

Shut down the VM fully (not just reboot) and start it again for the guest agent to connect. You can verify it's working:

qm agent 200 ping

If it returns without error, the agent is connected. You should also see the VM's IP address in the Proxmox summary tab now.

RDP Setup

The noVNC console is fine for installation, but for daily use you want RDP. It's faster, supports clipboard sharing, proper resolution scaling, and audio redirection.

Enable RDP in Windows:

Settings > System > Remote Desktop > Enable Remote Desktop
Confirm the firewall prompt

Or via PowerShell (faster):

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name "fDenyTSConnections" -Value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

Now you can connect from any RDP client using the VM's IP. If you're on Linux, I recommend Remmina or FreeRDP. On macOS, Microsoft Remote Desktop from the App Store works well.

Pro tip: set a static IP for the VM or create a DHCP reservation. Nothing more annoying than your RDP bookmark breaking because the VM got a new address.

# Example static IP configuration
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.1.50 -PrefixLength 24 -DefaultGateway 192.168.1.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.168.1.1,1.1.1.1

Performance Tweaks

CPU Configuration

If you haven't already, make sure your CPU type is set to host:

qm set 200 -cpu host

This exposes your actual CPU features to the guest, allowing Windows to use AVX, AES-NI, and other instruction sets. The default kvm64 type is deliberately minimal and will hurt performance.

For multi-socket hosts, keep sockets at 1 and increase cores. Windows licensing can be socket-aware, and most applications perform better with more cores on one socket than fewer cores across multiple sockets.

Memory Ballooning

VirtIO ballooning allows Proxmox to reclaim unused memory from the VM. This is useful when you're overcommitting memory across multiple VMs.

It's enabled by default after installing VirtIO guest tools. You can set a minimum memory:

qm set 200 -balloon 4096 -memory 16384

This tells Proxmox the VM has 16 GB allocated but can be ballooned down to 4 GB if memory pressure on the host demands it.

In my experience, ballooning works fine for general desktop VMs but I disable it for latency-sensitive workloads (gaming, real-time audio):

qm set 200 -balloon 0

Setting balloon to 0 disables ballooning entirely. The VM keeps all its allocated memory.

Disk Performance

If you're on ZFS storage, make sure you're using virtio-scsi-single with IO threads:

scsihw: virtio-scsi-single
scsi0: local-zfs:vm-200-disk-1,iothread=1,size=120G,ssd=1,discard=on

The iothread=1 parameter gives this disk its own dedicated I/O thread instead of sharing the main QEMU thread. The difference is measurable — I've seen sequential write speeds jump 20-30% with IO threads enabled.

Enable discard and SSD emulation so Windows sends TRIM commands, which ZFS translates to space reclamation on the pool.

Power Plan

Windows defaults to the "Balanced" power plan, which aggressively clocks down the virtual CPU. Switch to "High performance":

powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

Or if the high performance plan isn't listed:

powercfg /duplicatescheme 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c
powercfg /setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

This prevents Windows from throttling CPU frequency in the guest, which otherwise causes unnecessary latency.

Reducing Windows Bloat

A fresh Windows 11 install comes with a staggering amount of stuff you don't need in a VM. Here's what I strip out on every VM build.

Disable Telemetry

# Disable telemetry
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\DataCollection" -Name "AllowTelemetry" -Value 0 -Type DWord -Force

# Disable activity history
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -Name "EnableActivityFeed" -Value 0 -Type DWord -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\System" -Name "PublishUserActivities" -Value 0 -Type DWord -Force

Remove Pre-installed Apps

# Remove most built-in apps
Get-AppxPackage *Microsoft.BingNews* | Remove-AppxPackage
Get-AppxPackage *Microsoft.BingWeather* | Remove-AppxPackage
Get-AppxPackage *Microsoft.GetHelp* | Remove-AppxPackage
Get-AppxPackage *Microsoft.Getstarted* | Remove-AppxPackage
Get-AppxPackage *Microsoft.MicrosoftSolitaireCollection* | Remove-AppxPackage
Get-AppxPackage *Microsoft.People* | Remove-AppxPackage
Get-AppxPackage *Microsoft.WindowsFeedbackHub* | Remove-AppxPackage
Get-AppxPackage *Microsoft.Xbox* | Remove-AppxPackage
Get-AppxPackage *Microsoft.ZuneMusic* | Remove-AppxPackage
Get-AppxPackage *Microsoft.ZuneVideo* | Remove-AppxPackage
Get-AppxPackage *Clipchamp* | Remove-AppxPackage

Disable Search Indexing

In a VM, search indexing just wastes IOPS:

Stop-Service WSearch
Set-Service WSearch -StartupType Disabled

Disable Superfetch/SysMain

Same deal — this prefetching service makes sense on physical hardware with spinning disks but just adds write amplification on virtual disks:

Stop-Service SysMain
Set-Service SysMain -StartupType Disabled

Disable Windows Update Auto-Restart

Nothing ruins a running VM like an unexpected reboot for updates:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" -Name "NoAutoRebootWithLoggedOnUsers" -Value 1 -Type DWord -Force

Snapshots and Backups

Before you start customizing heavily, take a snapshot. Proxmox snapshots include the VM state (running memory) and all disks:

qm snapshot 200 fresh-install --description "Clean Windows 11 install with VirtIO drivers"

For regular backups, use the built-in Proxmox Backup system. I run nightly backups of all Windows VMs to a separate Proxmox Backup Server:

# Manual backup
vzdump 200 --storage pbs-storage --mode snapshot --compress zstd

Snapshot mode uses the QEMU guest agent to freeze the filesystem before taking a consistent backup. This is why getting the guest agent working is important — without it, you're taking crash-consistent backups at best.

Final Thoughts

The Windows 11 on Proxmox setup has gotten significantly smoother over the last few Proxmox releases. The TPM and Secure Boot emulation work reliably now, and the VirtIO drivers are mature enough that I've never had stability issues with them.

The biggest performance wins come from three things: using cpu: host, enabling IO threads on your virtual disks, and installing the VirtIO guest tools. Everything else is incremental optimization.

One last thing — if you're planning to do GPU passthrough to this Windows VM, get the base VM working with VirtIO and RDP first, then add the GPU. Debugging passthrough issues is much harder when you can't even get into the VM, and RDP gives you a reliable fallback display that works even when the GPU is acting up.