[Proxmox Series Part 5] Building a Standard Windows VM Profile

Even people who already run Proxmox confidently tend to re-search every Windows VM install. Windows 11 hardens UEFI, Secure Boot, TPM 2.0, and CPU checks; it also expects you to inject VirtIO drivers during setup. Skip those steps and Windows either refuses to install or boots with half-working storage and networking. Linux guests hide these details, but Windows guests require intentional driver loading, so a vetted baseline removes friction and keeps templates predictable.

This article walks through the default profile I recommend for Windows 11 inside Proxmox. We will cover UEFI/OVMF (the UEFI firmware bundle) versus q35 machine types, how Proxmox’s swtpm-backed TPM 2.0 behaves, VirtIO storage and network devices, guest agent installation, default storage and bridge choices, and the licensing/backups mistakes beginners most often make.

How this post flows

1. Why a Windows VM standard matters
2. Recommended virtual hardware profile
3. Required ISO files and prep work
4. Installation steps and driver order
5. Post-install checks and templating
6. Common mistakes you should avoid

Terms introduced here

1. OVMF: The project that provides UEFI firmware binaries. In Proxmox you pick the OVMF (UEFI) or OVMF secureboot BIOS option to load it.
2. q35 machine type: A QEMU chipset model based on Intel’s ICH9 platform. It exposes PCIe slots, TPM hooks, and ACPI features that Windows 10/11 expect, whereas the legacy i440fx lacks many of those capabilities.
3. VirtIO drivers: Paravirtualized drivers for storage and networking. Windows needs you to load them manually during setup for good performance.
4. Virtual TPM: A TPM 2.0 device Proxmox adds so Windows 11 passes its security checks.
5. Guest Agent: The qemu-guest-agent package for Windows that lets Proxmox read IP addresses, trigger graceful shutdowns, and quiesce the guest before backups.

Reading card

• Estimated time: 16 minutes
• Prereqs: Proxmox VE 8.x or newer, Windows 11 ISO, VirtIO driver ISO, licensing method (KMS/MAK/retail) confirmed
• After reading: you can build and reuse a Windows VM template with the correct defaults while avoiding TPM/licensing pitfalls.

Why a Windows VM standard matters

Windows guests demand more ceremony than Linux guests, and reinstalling becomes the only fix if you skip the wrong step. Windows 11 specifically requires UEFI, Secure Boot support, TPM 2.0, and a sufficiently recent CPU generation. Proxmox can relax the CPU check, but without TPM and UEFI the installer stops or future updates fail. Capturing the right defaults up front keeps every clone predictable.

Your standard should cover these six items:

1. BIOS: OVMF (UEFI), optionally the secureboot build, with the EFI disk on fast storage
2. Machine type: q35 with the latest QEMU version (use i440fx only for legacy ISOs)
3. Disk bus: VirtIO SCSI using qcow2 (snapshot- and backup-friendly)
4. Network: VirtIO NIC on the default bridge or a dedicated bridge/VLAN
5. Security: TPM 2.0 device and matching storage placement, Secure Boot keys if required
6. Guest agent/licensing: qemu-guest-agent installed and a plan for Windows activation

Recommended virtual hardware profile

When creating the VM in the Proxmox UI, start with these values so Windows 11 behaves well.

CPU and memory

• Sockets/Cores: 1 socket with 2–4 cores. Use the x86-64-v2-AES or host CPU type. host exposes nested virtualization, AES-NI, and other CPU flags to the guest.
• Memory: Minimum 6 GB, preferably 8 GB if you will run desktop workloads. Leave ballooning off during installation so unexpected reclaim does not crash Setup, then enable it only after burn-in if you need overcommit.

Board-related settings

• BIOS: Select “OVMF (UEFI)” (or the secureboot build) and store the EFI disk on SSD-backed storage. Secure Boot requires the matching OVMF code+vars image that ships with Proxmox 8.
• Machine: Choose q35. The older i440fx chipset limits PCIe slots, TPM exposure, and ACPI compliance.
• TPM State: Add a TPM 2.0 device (swtpm). Keep its storage on the same pool as the EFI disk so template clones don’t break. Avoid slow or remote storage for TPM state because every boot reads it.
• Display: Switch to VirtIO-GPU or SPICE so graphics drivers upgrade cleanly.

Storage and networking

• Disk bus: VirtIO SCSI with the controller set to “VirtIO SCSI single.” Enable IO Thread per disk for more predictable latency.
• Disk size: Allocate at least 64 GB. If the VM will run AD DS, WSUS, or other server roles, plan for 128 GB+.
• Cache: Write back when you have a UPS; Write through or Direct sync when you do not. Keep qcow2 space overhead in mind if you take snapshots.
• Network device: VirtIO (paravirtualized) tied to vmbr0 or another bridge/VLAN. Set the VLAN Tag field if you rely on tagged segments.

Required ISO files and prep work

Windows setup is smooth when you mount both ISO images up front. In the Hardware tab add two CD/DVD drives, attach the Windows ISO to one, the VirtIO ISO to the other, and make sure the boot order points to Windows first.

1. Windows 11 ISO: Download the official Microsoft image and upload it to your ISO storage.
2. VirtIO driver ISO: Grab the latest virtio-win release and upload it to the same storage.

After creating the VM, add two CD/DVD drives in the Hardware tab and attach each ISO. If the installer cannot see the disk, click Load driver and browse into the VirtIO ISO’s viostor folder for the amd64 driver.

Installation steps and driver order

1. Boot the VM, pick your language, and start the install.
2. When the disk selection screen shows nothing, click Load driver, point to viostor\w11\amd64 on the VirtIO ISO (use w10 or 2k22 folders for other versions), and load the driver.
3. Create your GPT partitions and continue the install. Confirm Windows and VirtIO ISOs remain attached for each reboot.
4. After the first boot, networking may still be offline. In Device Manager point the unknown NIC at NetKVM\w11\amd64 on the VirtIO ISO.
5. Install the remaining VirtIO components by running virtio-win-gt-x64.exe. This grabs balloon, pvpanic, storage, and serial drivers in one pass.
6. Finish by running qemu-ga-x86_64.msi from the guest-agent folder so Proxmox can read IPs and send shutdown commands.
7. Before Windows Update, validate the disk uses GPT/UEFI: run Get-Disk or diskpart -> list disk and confirm the asterisk appears under GPT.

Heads-up: Windows licensing is tied to the VM’s “hardware.” Sysprep the image before templating so each clone regenerates its SID and re-initializes TPM. If you change CPU type or reset TPM state later, be prepared to reactivate Windows.

Post-install checks and templating

Run through these checkpoints before you snapshot or convert the VM into a template:

• Device Manager shows no unknown devices.
• The Proxmox Summary tab reports the guest agent as "running."
• Windows Update runs cleanly with no Secure Boot or TPM complaints.
• Get-Disk or diskpart confirms the disk uses GPT under UEFI.
• slmgr /dlv shows the activation channel you expect.
• The VM appears on vmbr0 (or your internal bridge) with the expected DHCP lease or static IP.
• EFI and TPM files live on the same storage pool so clones carry both together.

Once everything looks good, either take a clean snapshot or click Convert to template. Cloning from this baseline is far faster than repeating the installer.

Common mistakes to avoid

1. Leaving the BIOS on SeaBIOS: Windows 11 setup fails or future updates break.
2. Skipping the VirtIO ISO: Windows defaults to IDE/E1000, tanking performance or blocking install entirely.
3. Splitting EFI and TPM storage: If the TPM state lives on another pool, clones throw errors and Windows sees the TPM as missing.
4. Ignoring the guest agent: Proxmox cannot report IPs, freeze filesystems for backup, or issue graceful shutdowns.
5. Write-back cache without power protection: Power loss can corrupt qcow2 images. Choose write-through if you lack a UPS.
6. Templating without Sysprep: Clones inherit the same SID and TPM state, confusing Windows activation. Always Sysprep/generalize before converting to a template.

Wrap-up

A single well-documented Windows VM profile removes hours of guesswork and makes Proxmox feel like a managed platform rather than a lab experiment. From here you can clone the VM for Active Directory tests, remote desktop gateways, or internal line-of-business apps in minutes. The next article shifts to lighter workloads: we will unpack how to standardize LXC containers, where their boundaries lie, and when you should avoid LXC altogether.