Proxmox VE: Windows-VMs mit VirtIO, TPM und Secure Boot

Aus maxTechCorner

Auf einen Blick

Gilt fürProxmox VE 9.1 und 9.2 mit Gästen Windows Server 2025 und Windows 11; virtio-win-Treiber-ISO, QEMU Guest Agent
BereichServer-Software
Dauerca. 1 Stunde pro Vorlage
RechteRolle PVEVMAdmin bzw. root@pam; lokale Administratorrechte in Windows
StandOktober 2026

Windows-VMs unter Proxmox VE richtig einrichten heißt: q35, UEFI mit Secure Boot, vTPM 2.0 und VirtIO-Treiber von Anfang an sauber konfigurieren. Diese Anleitung zeigt die empfohlenen Einstellungen für Windows Server 2025 und Windows 11, die Treiberinstallation im Setup, den QEMU Guest Agent und die Wahl des CPU-Typs. Am Ende steht eine Vorlage, aus der sich weitere VMs klonen lassen.

Windows-VM unter Proxmox VE: Windows-ISO, virtio-win-ISO, Maschinentyp q35 mit OVMF/UEFI und vTPM 2.0 fließen in eine VM mit VirtIO SCSI single, IO Thread, Discard, SSD-Emulation und VirtIO-Netzwerk. Ergebnis sind Secure Boot mit Microsoft-Schlüsseln von 2023, funktionierende Snapshots, Guest Agent für Backups und eine klonbare Vorlage.

Empfohlene Einstellungen im Überblick

Die Proxmox-Anleitung „Windows 2025 guest best practices“ und das Admin-Handbuch (Kapitel Qemu/KVM Virtual Machines) empfehlen für aktuelle Windows-Versionen folgende Werte. Sie gelten für Windows Server 2025, Windows Server 2022 und Windows 11 gleichermaßen.

Reiter im Assistenten Einstellung Empfehlung
OS Guest OS Microsoft Windows 11/2022/2025
System Machine q35 (Version wird bei Windows-Gästen beim Anlegen festgeschrieben)
System BIOS OVMF (UEFI) mit EFI-Disk, Pre-Enroll keys aktiv
System TPM Add TPM, Version v2.0
System SCSI Controller / Qemu Agent VirtIO SCSI single / Haken setzen
Disks Bus, Optionen SCSI; Discard, IO thread, SSD emulation
CPU Type x86-64-v2-AES (Standard) oder host, siehe unten
Memory Ballooning aktiv lassen, Balloon-Treiber installieren
Network Model VirtIO (paravirtualized)

Warum q35 und UEFI? Windows 11 setzt UEFI mit Secure Boot und TPM 2.0 voraus, Windows Server 2025 profitiert davon (BitLocker, Credential Guard, VBS). Der Maschinentyp q35 bildet einen PCIe-Bus nach und ist Voraussetzung für PCI Passthrough. Bei Windows-Gästen pinnt Proxmox die Maschinenversion beim Anlegen, damit sich die virtuelle Hardware nach einem QEMU-Update nicht ändert – Windows reagiert darauf sonst mit neuen Geräten oder einer erneuten Aktivierung.

Cache: Das Wiki nennt Write back für die beste Leistung; die Voreinstellung No cache ist sicherer. Write back nur mit USV und zuverlässigem Storage wählen.

VM anlegen: Weboberfläche und Kommandozeile

  1. Windows-ISO und die aktuelle stabile virtio-win-ISO (Fedora-Projekt, Archiv unter https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/) auf einen ISO-Storage hochladen: Datacenter › <Knoten> › local › ISO Images › Upload.
  2. Create VM starten, die Werte aus der Tabelle eintragen. Bei der EFI-Disk und dem TPM-State denselben Storage wie für die Systemplatte wählen.
  3. Nach dem Assistenten unter Hardware › Add › CD/DVD Drive ein zweites Laufwerk (Bus IDE, Nummer 0) mit der virtio-win-ISO hinzufügen.

Dasselbe auf der Kommandozeile (VM-ID 210, Storage local-zfs, Bridge vmbr0):

qm create 210 --name srv-win2025 --ostype win11 --machine q35 --bios ovmf \
  --cpu x86-64-v2-AES --cores 4 --memory 8192 --balloon 4096 \
  --scsihw virtio-scsi-single \
  --scsi0 local-zfs:80,iothread=1,discard=on,ssd=1 \
  --efidisk0 local-zfs:1,efitype=4m,pre-enrolled-keys=1 \
  --tpmstate0 local-zfs:1,version=v2.0 \
  --net0 virtio,bridge=vmbr0,firewall=1 \
  --ide2 local:iso/Windows_Server_2025.iso,media=cdrom \
  --ide0 local:iso/virtio-win.iso,media=cdrom \
  --agent enabled=1 --boot "order=scsi0;ide2"

Typische Fehler: EFI-Disk ohne efitype=4m (keine Secure-Boot-Unterstützung), Systemplatte auf IDE oder SATA statt SCSI (langsam, kein IO Thread) oder ein vergessener TPM-State – dann verweigert das Windows-11-Setup die Installation. Der TPM-State lässt sich nach dem Anlegen nicht mehr ändern, nur entfernen und neu anlegen.

Windows installieren und VirtIO-Treiber laden

Das Windows-Setup kennt den VirtIO-SCSI-Controller nicht und zeigt zunächst keine Festplatte an.

  1. Im Setup Benutzerdefiniert wählen und bei der Laufwerksauswahl Treiber laden anklicken.
  2. Speicher: auf der virtio-win-CD vioscsi\2k25\amd64 öffnen (Windows 11: vioscsi\w11\amd64) und Red Hat VirtIO SCSI pass-through controller wählen.
  3. Netzwerk: NetKVM\2k25\amd64 bzw. NetKVM\w11\amd64 – Red Hat VirtIO Ethernet Adapter.
  4. Balloon: Balloon\2k25\amd64 bzw. Balloon\w11\amd64 – VirtIO Balloon Driver.
  5. Danach erscheint die Platte; Installation wie gewohnt fortsetzen.

Nach dem ersten Start auf der virtio-win-CD virtio-win-gt-x64.msi ausführen (installiert alle übrigen Treiber; Qxl und Spice abwählen, wenn SPICE nicht genutzt wird) und anschließend guest-agent\qemu-ga-x86_64.msi. Im Geräte-Manager prüfen, dass kein unbekanntes Gerät übrig ist; andernfalls Treiber aktualisieren mit der CD und Unterordner einbeziehen.

Netzwerk-Multiqueue: Bei VMs mit hoher Netzlast in den Eigenschaften der Netzwerkkarte Multiqueue auf die Zahl der vCPUs setzen.

QEMU Guest Agent, Ballooning und Snapshots

Der QEMU Guest Agent meldet IP-Adressen und Speicherverbrauch an die Übersichtsseite, ermöglicht sauberes Herunterfahren und friert vor einem Backup die Dateisysteme ein (guest-fsfreeze-freeze/-thaw, unter Windows über VSS). Voraussetzungen:

  • Option Options › QEMU Guest Agent aktiv (CLI: qm set 210 --agent enabled=1).
  • Nach dem Aktivieren die VM einmal herunterfahren und neu starten – ein Neustart aus Windows heraus reicht nicht.
  • Prüfen mit qm agent 210 ping; ohne Fehlermeldung ist der Agent erreichbar.

Ballooning ist standardmäßig aktiv, auch bei fester Speichergröße, weil der Balloon-Treiber den tatsächlichen Verbrauch meldet. Mit Minimum memory kleiner als Memory gibt Windows bei knappem Host-RAM Speicher zurück; Proxmox zielt dabei auf eine Host-Auslastung von 80 %. Für Datenbank- und Exchange-Server ist eine feste Zuweisung ohne Minimum die ruhigere Wahl.

Snapshots mit TPM: Seit Proxmox VE 9.1 kann der TPM-State im qcow2-Format liegen. Damit funktionieren Snapshots von VMs mit vTPM auch auf Datei-Storage wie NFS oder CIFS; auf ZFS, LVM-Thin und Ceph RBD waren sie schon vorher möglich. Version 9.2 erlaubt zusätzlich Live-Snapshots mit TPM auf Storages mit Snapshots als Volume-Chains (Tech Preview) und unterstützt TPM-State auf iSCSI. Ein Snapshot ersetzt kein Backup – dafür gibt es den Proxmox Backup Server.

Sicherheit des vTPM: Ein emulierter TPM liegt als normales Volume auf dem Storage. Wer Zugriff auf den Storage oder die Backups hat, kann ihn auslesen. BitLocker in der VM schützt daher vor allem bei Diebstahl einzelner Platten; Backups und Storage müssen zusätzlich geschützt werden.

CPU-Typ: x86-64-v2-AES oder host?

CPU-Typ Vorteil Nachteil Empfehlung
x86-64-v2-AES (Standard der Oberfläche) Live-Migration zwischen unterschiedlichen Intel- bzw. AMD-Generationen fehlende neuere Befehlssätze, etwas weniger Leistung Cluster mit gemischter Hardware
host volle Leistung und alle CPU-Funktionen Live-Migration nur zwischen Knoten mit identischer CPU und Microcode Einzelserver, homogene Cluster, WSL/Hyper-V in der VM
benanntes Modell (z. B. ältestes Modell im Cluster) Kompromiss aus Leistung und Migrierbarkeit Pflegeaufwand bei neuer Hardware reine Intel- oder reine AMD-Cluster
  • Live-Migration zwischen Intel- und AMD-Hosts ist nicht garantiert – einen Cluster nicht mischen.
  • Proxmox VE 9.2 erlaubt eigene CPU-Modelle direkt in der Weboberfläche, etwa als gemeinsamer Nenner für einen Cluster.
  • Bekanntes Problem in 9.2: Auf Intel-Hosts können Windows-11/2022/2025-VMs mit CPU-Typ host und aktivierter virtualisierungsbasierter Sicherheit (VBS) sporadisch einfrieren. Treten solche Hänger auf, ein benanntes CPU-Modell oder x86-64-v2-AES verwenden.
  • Für WSL oder Hyper-V in der VM CPU-Typ host und verschachtelte Virtualisierung aktivieren (seit 9.1 als vCPU-Flag nested-virt).

Secure-Boot-Zertifikate 2023 und Vorlagen

Die Microsoft-Secure-Boot-Zertifikate von 2011 sind im Juni 2026 abgelaufen. Seit Proxmox VE 9.1 enthalten neu angelegte EFI-Disks die Microsoft-UEFI-CA-2023-Schlüssel; die Oberfläche zeigt sie mit dem Vermerk ms-cert=2023k. Ältere VMs sollten nachgerüstet werden:

# In Windows vorher BitLocker-Schutz aussetzen (sonst fragt Windows nach dem Wiederherstellungsschlüssel):
#   manage-bde -protectors -disable C:
qm shutdown 210
qm enroll-efi-keys 210
qm start 210

In der Oberfläche heißt die Funktion Hardware › EFI Disk › Disk Action › Enroll Updated Certificates. Nach dem Start BitLocker wieder aktivieren (manage-bde -protectors -enable C:).

Vorlage bauen: Updates installieren, Treiber und Guest Agent prüfen, mit sysprep /generalize /oobe /shutdown verallgemeinern und die VM über More › Convert to template in eine Vorlage umwandeln. Neue Server entstehen per Clone (Full Clone für unabhängige VMs). Das spart pro Server die Treiberinstallation.

Hinweise

  • Lizenzierung: Windows Server wird pro physischem Kern des Hosts lizenziert; in einem Cluster mit Live-Migration muss jeder Knoten ausreichend lizenziert sein, auf dem die VM laufen kann. Standard-Edition deckt zwei VMs pro vollständig lizenziertem Host ab, Datacenter unbegrenzt viele.
  • Migration von VMware: Importierte VMs laufen zunächst oft mit SATA und E1000; erst VirtIO-Treiber installieren, dann umstellen. Details in Proxmox VE: Migration von VMware ESXi.
  • Zeit und Domäne: Domänencontroller beziehen die Zeit von einer externen Quelle; die Zeitsynchronisierung über den Guest Agent ersetzt das nicht.
  • Bei Planung, Lizenzierung und Betrieb von Windows-Servern auf Proxmox unterstützt Sie die Microsoft-Windows-Beratung von m.a.x. it.

Siehe auch

Links und Quellen


Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung? Kontakt aufnehmen