Windows 11 VM on Proxmox: Practical Home Lab Development Sandbox

My Windows 11 virtual machine on Proxmox is the quiet workhorse of my home lab — the one instance I rely on every day for development, testing, and occasional GPU-accelerated adventures.

Background / Overview​

Running a Windows 11 VM as a primary development environment on Proxmox VE (PVE) is no longer an oddball trick — it’s a pragmatic choice for developers who need Windows-only tooling alongside a sea of Linux services. Proxmox blends KVM virtual machines and lightweight Linux containers (LXC), giving hobbyists and homelabbers a flexible orchestration plane that can host everything from Home Assistant to nested ESXi. In my stack, a Windows 11 VM sits next to a handful of LXCs and Linux VMs, and it handles Visual Studio, .NET builds, PowerShell experimentation, nested Hyper-V/WSL2, and even GPU tasks via passthrough to an Intel Arc A750.
This article walks through the design decisions, configuration tweaks, benefits, and the real-world risks of treating a Windows 11 VM on Proxmox as your daily driver — plus actionable guidance so you can replicate (or avoid) the same choices.

---

Why a Windows 11 VM? Practical motivations​

I picked a Windows 11 VM for several very pragmatic reasons:

• Toolchain compatibility: Full Visual Studio (not VS Code), .NET tooling, certain proprietary debuggers and installers, and Windows-specific build systems still run best on native Windows.
• Isolation for experimentation: Installing dozens of dev kits, language runtimes, and oddball utilities on a primary workstation quickly creates dependency hell. A VM isolates that mess and gives me a clean rollback surface.
• PowerShell and Windows automation: A disposable Windows environment lets me break things while learning automation and build scripts without risking my main workstation.
• Feature breadth: With Proxmox features like snapshots, virtio drivers, host-CPU mode, and GPU passthrough, a VM can approach the utility of a physical machine for many workflows.

These are the practical forces behind my decision: compatibility, isolation, and recoverability.

---

Core configuration choices that make this VM “work”​

1) CPU: use the Host CPU type for maximum feature exposure​

Setting the VM processor type to host is the single most impactful tweak for a dev-focused VM. Using CPU type "host" exposes the underlying CPU’s full feature set and instruction flags directly to the guest, removing much of the emulation surface and enabling nested virtualization features reliably.

• Benefit: The guest sees the same virtualization and instruction-set extensions as the host, which is crucial when you need nested Hyper-V or hardware acceleration inside the VM.
• Tradeoff: Live migration between heterogeneous hosts becomes problematic if the target CPU lacks flags the guest expects.

Recommendation: Use host CPU type when you’re running VMs on a single node (or a homogeneous cluster) and care about nested virtualization or maximum performance.

2) Paravirtualized I/O: VirtIO drivers and VirtIO-SCSI​

To avoid the “Windows setup can’t find any drives” trap and to get the best disk and network performance, install the VirtIO driver suite inside the Windows guest.

• Use VirtIO-SCSI (virtio-scsi) as the SCSI controller for VM disks — Proxmox recommends it for performance and features.
• Attach the virtio-win ISO during Windows installation so you can load drivers at install time for the SCSI controller and the network adapter (virtio-net).

Why it matters: Paravirtualized drivers reduce CPU overhead and provide near-native I/O throughput for VMs. This is a must for development workloads that hit disk and network often.

3) vTPM and Secure Boot for Windows 11 compatibility​

Windows 11 checks for TPM 2.0 and Secure Boot for many of its features. Proxmox supports a virtual TPM (vTPM) and UEFI firmware options (OVMF) so a VM can pass the Windows 11 health checks and use BitLocker or other TPM-backed features.

• The practical benefit is full Windows 11 feature parity inside the VM (BitLocker, some security features).
• Note: vTPM state must be protected. Losing the TPM state file used by the VM can complicate BitLocker recovery.

4) Nested virtualization: running Hyper-V, WSL2, and more inside the VM​

To run Hyper-V or WSL2 inside a PVE guest, you need to expose virtualization extensions to the VM:

• Enable nested virtualization on the host kernel (if required) for your CPU vendor.
• Configure the VM to use cpu: host (or a similar cputype) and ensure KVM is enabled.
• If necessary, add hypervisor flags to the VM config to ensure the guest’s hypervisor features initialize cleanly.
• Benefit: This enables Windows features like Hyper-V and WSL2 so you can run containers, VMs, and Windows-native virtualization tools inside the guest.
• Caveat: Nested virtualization adds CPU overhead, and not all workloads will behave identically to a bare-metal Hyper-V host.

---

GPU passthrough: turning a VM into a GPU-capable workstation​

GPU passthrough is a game changer for a desktop-grade Windows VM. In my setup I pass through an Intel Arc A750 to the Windows guest. That lets me:

• Do GPU-accelerated video edits, machine learning workloads, and occasional gaming inside the VM.
• Keep the Proxmox host focused on self-hosted services and containers.

Key setup steps and considerations:

• Enable IOMMU in the host firmware (Intel VT-d or AMD IOMMU) and in the kernel boot parameters.
• Enable “Above 4G decoding” / 4G decoding in firmware when passing through modern GPUs.
• Load VFIO kernel modules on the host (vfio, vfio_pci, vfio_iommu_type1).
• Isolate the GPU into its own IOMMU group. If your platform lacks clean grouping, you may need an ACS override — but this is a security and stability tradeoff.
• Do not pass the host’s primary GPU unless you have out-of-band host access (IPMI / remote KVM). Passing the host display GPU can make the host unreachable.

Performance-wise, the Intel Arc A750 is a capable mid-range card with 8 GB of GDDR6 memory and solid 1080p/1440p performance for many workloads; it’s not a high-end compute device but offers great value for desktop-style GPU acceleration inside a VM.
Risks and pitfalls:

• Some GPUs lack vendor-reset support and can hang on warm reassignments.
• Driver mismatches between host and guest or old QEMU versions can cause black screens.
• Passing GPUs affects migration — moving VMs with passthrough is non-trivial.

---

Snapshots, backups, and easy recovery: a real advantage​

One of the most tangible benefits of running an experimental Windows 11 instance in Proxmox is rapid recovery.

• Snapshots let you freeze a VM state and revert within minutes. For testing risky updates, drivers, or experimental tool installs, this is a lifesaver.
• Proxmox Backup Server (PBS) complements snapshots by sending incremental uploads and applying server-side deduplication, which reduces storage usage and speeds up repeated backups of similar VM states.

Important operational notes:

• Snapshots are fantastic for short-term rollback and testing, but they are not a substitute for off-node backups. Keep regular, tested PBS backups for any data you can’t afford to lose.
• PBS uses chunking and deduplication strategies optimized for image archives and file archives; this makes storing repeated incremental backups of a VM storage-efficient.
• Because snapshots are quick, they encourage bold experimentation. But always verify restores (test your backups) to avoid “it looked fine, but restore failed” surprises.

---

My Windows 11 VM: software and roles​

The VM is essentially my all-purpose Windows sandbox:

• Primary dev tools: Visual Studio (full), Code Server (self-hosted fork of VS Code), Git Bash, Chocolatey for package management.
• DevOps & virtualization: Hyper-V, WSL2, Podman Desktop, nested VMs for testing.
• Utilities: Total Commander and PowerShell modules to automate builds and maintenance tasks.
• GPU workflows: Video editing, occasional model inference tasks, and gaming tests via the Arc A750 passthrough.

This gives me a single place to iterate on code and infrastructure; and because the VM uses nested virtualization, I can spin up ephemeral environments inside it without touching the host.

---

Step-by-step: configuration checklist (practical, condensed)​

• Provision VM with OVMF (UEFI) and add an EFI disk.
• Set CPU type to host (unless you need live migration across different CPU families).
• Add TPM v2.0 to the VM and enable Secure Boot.
• Attach Windows 11 ISO and the virtio-win ISO for drivers before installation.
• Set SCSI controller to virtio-scsi and use VirtIO network adapter.
• Configure passthrough devices (GPU) only after verifying IOMMU grouping on the host.
• Enable nested virtualization on the host kernel if you plan to run Hyper-V/WSL2.
• Configure a scheduled PBS backup job and take snapshots before major experiments.

---

Strengths: why this setup works so well​

• Separation of concerns: Keeps my messy developer installs away from my daily driver and host OS.
• Fast recovery: Snapshots plus PBS dedup allow fast rollback and efficient storage.
• Versatility: The VM runs developer tools, nested virtualization, and GPU workloads.
• Cost-efficiency: A modest home server with a midrange GPU can replace a second physical “dev” machine for many tasks.
• Reproducibility: VM definitions and snapshots let you recreate environments reliably.

---

Risks and caveats: what can go wrong​

• Complexity & maintenance: GPU passthrough, nested virtualization, and vTPM all add complexity. Each change is a potential failure point.
• Licensing considerations: Running Windows in a VM requires compliance with Microsoft licensing terms — check retail, OEM, and volume license rules for your scenario.
• BitLocker and TPM state: Losing the TPM state file or backups for encrypted volumes can lock you out; handle TPM state with care.
• Security tradeoffs: Using ACS override or other kernel tweaks to achieve passthrough can reduce isolation or expose vulnerabilities.
• Stability variance: Hardware, BIOS quirks, GPU firmware, and QEMU versions can cause issues like black screens or hangs; troubleshooting these can be time-consuming.
• Migration limitations: Host-CPU mode and passthrough devices make live migration difficult or impossible between heterogeneous hosts.

Wherever I use an advanced tweak (ACS override, patched drivers, or experimental firmware), I treat that VM as less stable and rely on nightly backups.

---

Troubleshooting highlights (real-world pain points)​

• If the Windows installer can’t find disks, it usually means the VirtIO SCSI driver wasn’t loaded; attach the virtio-win ISO and load the driver from the viostore/w11/amd64 directory.
• If nested Hyper-V features appear blocked, ensure nested virtualization is enabled in the host kernel and the VM is set to host CPU type; sometimes extra QEMU flags are required to surface the hypervisor bit to the guest.
• GPU passthrough black screens often trace back to IOMMU isolation, missing vendor reset, or driver incompatibilities — check device binding and host dmesg logs when diagnosing.
• If BitLocker prompts or TPM errors arise after a restore, check vTPM state and the VM’s TPM metadata; always have recovery keys safely stored outside the VM.

---

Best practices and operational hygiene​

• Keep a separate, tested backup of BitLocker recovery keys and vTPM state where appropriate.
• Use PBS for incremental backups and rely on deduplication to control storage; still keep periodic full off-node backups for critical data.
• Maintain a host-level recovery plan that includes console access (IPMI/KVM-over-IP) if you pass through the host’s primary GPU.
• Test restores routinely — a backup that never gets restored is not proven.
• Keep Proxmox and QEMU versions reasonably up to date, and follow vendor guidance for critical features like VFIO and swtpm.

---

Final verdict: is a Windows 11 VM on Proxmox right for you?​

For developers who need the Windows ecosystem but want the flexibility and safety of virtualization, a Proxmox-hosted Windows 11 VM is an excellent option. It combines the best of both worlds:

• The full Windows toolchain and features.
• The isolation and recoverability that only virtualization provides.
• The ability to offload GPU tasks with passthrough, making the VM usable beyond mere testing.

That said, this setup is not “set-and-forget.” Running nested virtualization, vTPM, and GPU passthrough in a production-critical environment requires discipline: rigorous backups, cautious firmware and driver management, and a willingness to troubleshoot low-level hardware and kernel interactions.
If your goals are to learn, experiment, and maintain a single, flexible development environment that doesn’t clutter your daily machine — this approach is powerful and practical. If, however, you need rock-solid, 24/7 production uptime with minimal maintenance, treat this configuration as a capable but more hands-on choice and plan accordingly.

---

Closing thoughts​

The appeal of a Proxmox-hosted Windows 11 VM is its combination of familiarity and capability: you get a Windows workspace that behaves much like a physical PC, but with the safety net of snapshots, the compactness of deduplicated backups, and the power of modern paravirtualized I/O and GPU passthrough. It’s the ideal middle ground for a home lab where flexibility and experimentation are the point.
Treat the VM as an experimental platform first and production second. With that mindset — and a disciplined backup/restore routine — a Windows 11 VM on Proxmox becomes more than a convenience: it becomes the central hub of a versatile, resilient home lab.

---

Source: XDA This is my favorite VM to run on Proxmox