BUBUKISTE.DE

Schlagwort: qemu

  • Die optimale PROXMOX VM Konfiguration für Windows Server

    Die optimale PROXMOX VM Konfiguration für Windows Server

    General:

    Name: Frei wählbar

    Resource Pool: Im Beispiel nicht genutzt. In dem verlinkten Artikel werden Sinn und Zweck des sogenannten Poolings genau erklärt und mit einer bebilderten Anleitung wird auch gezeigt, wie ein Resource Pool in Proxmox erstellt und verwendet wird.

    https://www.vinchin.com/de/vm-backup/proxmox-resource-pools.html


    OS:

    Woher bekomme ich das aktuelle VirtIO ISO Image mit den Treibern für den Betrieb von Microsoft Systemen?

    https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers


    System:


    Warum bei Machine Q35 für Windows Server 2019?

    Moderne Hardware-Unterstützung (bessere Kompatibilität mit neuen Treibern)

    Bessere Performance durch PCIe (falls du später z. B. eine GPU durchreichen willst)

    Zukunftssicher (i440FX ist veraltet und wird irgendwann weniger unterstützt)

    Einzige Ausnahme: Falls ältere Legacy-Anwendungen oder Treiber zum Einsatz kommen sollen, die nur mit i440FX funktionieren.

    Featurei440FXQ35 (empfohlen)
    ChipsatzÄlter (1996, PIIX3)Neuer (Intel Q35, PCIe-Unterstützung)
    PCIe-UnterstützungNeinJa (bessere Hardwarekompatibilität)
    LeistungsfähigkeitGut für ältere OSBesser für moderne Windows-Versionen
    Pass-Through-UnterstützungEingeschränktBessere Unterstützung für PCIe-Pass-Through

    Warum „SCSI / VirtIO SCSI“?

    Für Windows Server 2019 in Proxmox wird SCSI mit VirtIO-SCSI-Controller empfohlen, da es mehr Features und eine bessere Performance bietet.

    FeatureVirtIO-BlockVirtIO-SCSI (empfohlen)
    PerformanceSchnellEin Controller für mehrere Disks
    Mehrere LaufwerkeJeder Datenträger braucht eigenen ControllerEin Controller für mehrere Disks
    TRIM/Discard-UnterstützungNeinJa (wichtig für SSDs)
    IOThreads-UnterstützungNeinJa (bessere Parallelverarbeitung)
    Windows-KompatibilitätFunktioniertBessere Treiber-Unterstützung
    Snapshots & Backups in ProxmoxEingeschränktBesser unterstützt

    EFI ja oder nein?

    • BIOS: OVMF (UEFI) wird empfohlen, aber SeaBIOS geht auch

    • EFI-Speicher: Aktivieren (falls UEFI genutzt wird)


    QEMU Agent ja oder nein?

    Qemu-Agent: Nur so ist es möglich, das Proxmox die VM korrekt herunterfahren kann


    TPM ja oder nein?

    Für Windows Server 2019 Essentials ist TPM nicht zwingend erforderlich, aber es kann sinnvoll sein, wenn du bestimmte Sicherheitsfunktionen nutzen möchtest.

    Wann TPM aktivieren?

    Ja, aktivieren, wenn:

    •               Du BitLocker für Laufwerksverschlüsselung nutzen willst

    •               Du Windows Defender Credential Guard oder andere Sicherheitsfeatures brauchst

    •               Du langfristig auf Windows Server 2022 oder Windows 11 upgraden möchtest

    Ohne TPM, wenn:

    •               Du keine speziellen Sicherheitsfeatures brauchst

    •               Du Ressourcen sparen willst (minimaler Overhead, aber dennoch vorhanden)

    Empfohlene Konfiguration:

    •               Falls du nur testen oder Basisfunktionen nutzen willst → Ohne TPM

    •               Falls du den Server produktiv nutzen und absichern willst → Mit TPM (Version 2.0)


    Disks:


    Warum 100 GB?

    Die Mindestanforderung liegt bei 60 GB, aber 100 GB sind eine gute Wahl für Updates, Logs und eventuelle Rollen/Dienste.


    Warum „Discard“?

    “Discard” (TRIM) sollte aktiviert werden, wenn die VM auf einer SSD oder einem Thin-Provisioned-Storage läuft.

    Vorteile:

    • Freigabe von nicht mehr genutztem Speicherplatz → VM gibt ungenutzte Blöcke an Proxmox zurück

    • Weniger Speicherverbrauch auf dem Host (besonders bei qcow2 oder ZFS)

    • Verbesserte SSD-Lebensdauer (durch weniger unnötige Schreibvorgänge)

    Wann aktivieren?

    Ja, aktivieren, wenn:

    • Die VM auf SSD oder NVMe liegt

    • Dein Proxmox-Storage Thin-Provisioning unterstützt (qcow2, ZFS, LVM-Thin)

    Nein, nicht aktivieren, wenn:

    • Die VM auf einer HDD mit LVM ohne Thin-Provisioning läuft

    • Du eine RAW-Festplatte ohne Thin-Provisioning nutzt (keine Wirkung)


    Warum „Skip Replication?

    Die Option “Skip Replication” in Proxmox bedeutet, dass die VM-Festplatte nicht in eine Proxmox-Storage-Replikation (z. B. ZFS-Replikation) einbezogen wird.

    Ja, aktivieren (Skip Replication = ON), wenn:

    • Die VM nicht auf einem replizierten Storage liegt (z. B. keine ZFS-Replikation)

    • Du die VM nicht zwischen Knoten synchronisieren willst

    • Die VM auf einem nicht-replizierbaren Storage läuft (z. B. LVM ohne Thin-Provisioning, Ceph RBD ohne Replikation)

    Nein, deaktivieren (Skip Replication = OFF), wenn:

    • Du ZFS- oder Ceph-Replikation zwischen mehreren Proxmox-Hosts nutzt

    • Die VM automatisch zwischen Knoten synchronisiert werden soll

    Empfehlung:

    • Falls du nur eine einzelne Proxmox-Node hast und keine Replikation nutzt → “Skip Replication” aktivieren

    • Falls du später eine Cluster-Replikation planst → “Skip Replication” deaktivieren


    Warum „SSD Emulation“?

    SSD-Emulation aktivieren, wenn auf SSD installiert

    SSD-Emulation sollte aktiviert werden, wenn die VM auf einer SSD oder NVMe läuft.

    Vorteile:

    •  Windows Server erkennt die virtuelle Festplatte als SSD → Kein unnötiges Defragmentieren

    •  Bessere Performance (Windows passt seine Speicherverwaltung an SSDs an)

    •  TRIM-Unterstützung (wichtig für SSDs, um ungenutzte Blöcke freizugeben)

    Wann aktivieren?

    •  Falls dein Proxmox-Storage eine echte SSD oder NVMe ist → Ja, aktivieren!

    • Falls die VM auf einer HDD läuft → Nein, deaktiviert lassen!

    Empfohlene Konfiguration:

    1. VirtIO-SCSI als Festplattencontroller nutzen

    2. IOThread aktivieren (falls mehrere Platten vorhanden sind)

    3. SSD-Emulation aktivieren, wenn der Storage eine SSD ist

    Falls der Proxmox-Host nur HDDs hat, bringt die SSD-Emulation keinen Vorteil.


    Warum „SCSI / VirtIO SCSI“?

    Für Windows Server 2019 in Proxmox wird SCSI mit VirtIO-SCSI-Controller empfohlen, da es mehr Features und eine bessere Performance bietet.

    FeatureVirtIO-BlockVirtIO-SCSI (empfohlen)
    PerformanceSchnellEin Controller für mehrere Disks
    Mehrere LaufwerkeJeder Datenträger braucht eigenen ControllerEin Controller für mehrere Disks
    TRIM/Discard-UnterstützungNeinJa (wichtig für SSDs)
    IOThreads-UnterstützungNeinJa (bessere Parallelverarbeitung)
    Windows-KompatibilitätFunktioniertBessere Treiber-Unterstützung
    Snapshots & Backups in ProxmoxEingeschränktBesser unterstützt

    Warum “No Cache” für Windows-VMs?


    1. Datensicherheit & Schutz vor Datenverlust

    • “No Cache” bedeutet, dass die VM-Daten direkt auf die Festplatte des Hosts geschrieben werden – ohne zwischengespeichertes Caching im RAM.

    • Falls der Host abstürzt oder Strom verliert, bleiben die Daten intakt, da nichts im Cache verloren geht.


    2. Bessere Stabilität bei hohen Schreiblasten

    • Windows Server kann hohe IOPS erzeugen (z. B. bei SQL-Servern oder AD-DCs).

    • “No Cache” reduziert die Wahrscheinlichkeit von Inkonsistenzen und Datenkorruption, da es den Schreibpfad direkter macht.


    3. Kompatibilität mit VirtIO & Windows Caching-Mechanismen

    • Windows hat bereits eigene Write-Back-Caching-Mechanismen, die mit VirtIO-SCSI oder VirtIO-Block gut funktionieren.

    • Wenn zusätzlich noch Write-Back Caching auf dem Proxmox-Host aktiv ist, kann es zu Datenverlust kommen, falls der Host ausfällt.


    IO Thread ja oder nein?

    IOThreads aktivieren, wenn VirtIO SCSI verwendet wird.

    Ja, aktivieren für:

    • VirtIO-SCSI-Controller (empfohlen)

    • Schneller NVMe- oder SSD-Storage

    • Mehrere virtuelle Festplatten (paralleler Zugriff verbessert Performance)

    Nicht aktivieren für:

    • IDE oder SATA (kein Vorteil, kann instabil werden)

    • HDDs mit geringem IOPS (kaum Performance-Gewinn)

    Vorteile von IOThreads:

    • Mehrere I/O-Operationen parallel → Bessere Performance bei mehreren Platten

    • Bessere Lastverteilung auf CPU-Kerne

    Empfohlene Konfiguration:

    • VirtIO-SCSI als Controller nutzen

    • IOThread pro Festplatte aktivieren (z. B. wenn du mehrere virtuelle Disks genutzt werden)


    CPU:

    In Proxmox ermöglicht die NUMA-Option auch Hot-Plugging für Speicher und CPU. Ohne diese Option funktioniert Hot-Plugging für CPU und Speicher überhaupt nicht.

    Es ist i.d.R. nicht sinnvoll mehr als vier CPU-Kerne zu verwenden. Ggf. den Arbeitsspeicher erhöhen oder mit redundanten Servern.


    Warum nur 4 CPU-Kerne für eine Windows Server VM?


    1. Effizientere CPU-Nutzung & Scheduling

    • Proxmox muss die CPU-Kerne der VMs mit den physischen Kernen des Hosts abstimmen.

    • Zu viele virtuelle CPUs (vCPUs) können den Scheduler überlasten, was zu schlechterer Performance führt.

    • Bei einem Host mit 8 oder 12 Kernen ist eine VM mit 4 Kernen oft ideal, um den Overhead gering zu halten.


    2. Windows Server benötigt nicht immer viele Kerne

    • Viele Windows Server arbeiten mehr mit RAM und I/O als mit CPU.

    • Domain Controller, Datei- und Druckserver, kleine Webserver brauchen oft nicht mehr als 2–4 Kerne.

    • Mehr Kerne bringen nur Vorteile, wenn die Workloads stark parallelisiert sind (z. B. SQL-Server oder Virtualisierung).


    3. NUMA & CPU-Pinning vermeiden Performance-Probleme

    • Falls dein Host eine Dual-Socket-CPU oder NUMA-Architektur hat, kann eine VM mit zu vielen Kernen über NUMA-Grenzen hinweg verteilt werden → Leistungsabfall.

    • 4 Kerne passen oft in eine NUMA-Node, was bessere Speicher- und Cache-Zugriffe bedeutet.


    4. Reduzierte Lizenzkosten (Windows Server Lizenzmodell)

    • Windows Server 2019/2022 wird pro Core lizenziert.

    • Die Standard-Lizenz deckt nur 16 physische Kerne pro Host ab, weshalb viele Admins kleinere VMs mit wenigen Kernen bevorzugen.

    • Essentials-Edition hat zudem eine Limitierung von maximal einem Sockel und 10 vCPUs.


    5. Ressourcenverteilung für mehrere VMs

    • Falls du mehrere Windows-VMs auf Proxmox laufen lassen willst, solltest du die CPU-Kerne sinnvoll aufteilen.

    • Ein Server mit 8–12 physischen Kernen sollte nicht zu viele vCPUs pro VM vergeben, um Staus zu vermeiden.

    Wann sind mehr als 4 Kerne sinnvoll?

    SQL- oder Exchange-Server: Hochparallele Workloads profitieren von 6–8 Kernen oder mehr.

    Terminalserver (RDS): Falls viele User gleichzeitig arbeiten, können 6+ Kerne nützlich sein.

    Hohe Netzwerk-/Storage-I/O: Bei sehr hoher Netzwerklast (z. B. Hyper-V mit SMB Direct) können mehr Kerne helfen.

    Fazit: Warum für eine Windows Server VM nur 4 CPU-Kerne in Proxmox?

    • Bessere CPU-Auslastung & weniger Scheduling-Probleme

    • Windows Server braucht nicht immer viele Kerne (außer bei spezialisierten Workloads)

    • Lizenzkosten optimieren (besonders bei Standard- oder Essentials-Edition)

    • Bessere NUMA-Nutzung & Speicherzugriffe

    Warum sollte “AES-NI” für eine Windows Server VM in Proxmox aktiviert sein?

    Die AES-NI (Advanced Encryption Standard – New Instructions) Erweiterung ist eine CPU-Funktion, die hardwarebeschleunigte Verschlüsselung ermöglicht. Für eine Windows Server VM in Proxmox gibt es mehrere gute Gründe, diese Funktion zu aktivieren:


    1. Schnellere Verschlüsselung & Entschlüsselung

    • AES-NI sorgt für eine massive Geschwindigkeitssteigerung bei der Verarbeitung von verschlüsselten Daten.

    • Besonders wichtig, wenn der Windows Server Funktionen wie:

    • BitLocker (Verschlüsselung von Festplatten)

    • IPsec VPNs (z. B. für Site-to-Site oder Remote-Zugriff)

    • HTTPS/SSL-Verschlüsselung (IIS, Webserver, Exchange, RDP, SQL-Server) nutzt.


    2. Performance-Boost für Windows Server-Funktionen

    Windows nutzt AES-NI automatisch für:

    BitLocker (Festplattenverschlüsselung) → Deutlich schnelleres Booten & geringere CPU-Last.

    IPsec (VPN & Netzwerkverschlüsselung) → Höhere Performance bei verschlüsselten VPN-Verbindungen.

    Windows Defender & TLS/SSL (HTTPS, Web-Dienste) → Geringere CPU-Last bei verschlüsselten Verbindungen.

    Dateiserver mit SMB 3.0 (Verschlüsselung & Signing) → Verbesserte Geschwindigkeit für verschlüsselte Dateifreigaben.

    Ohne AES-NI müsste Windows die Verschlüsselung per Software lösen, was die CPU stark belasten kann.


    3. Geringere CPU-Auslastung & Energieverbrauch

    • AES-NI entlastet die CPU, weil die Verschlüsselung direkt in der Hardware stattfindet.

    • Das reduziert die CPU-Last & Stromverbrauch im Vergleich zu softwarebasierter Verschlüsselung.

    • Besonders bei hohen Datenmengen (Datenbankserver, RDS-Server, Datei- & Webserver) wichtig.


    4. Sicherere Virtualisierung (Hyper-V & Windows Shielded VMs)

    • Falls Windows Server in der VM als Hyper-V-Host fungiert (Nested Virtualization), kann AES-NI helfen.

    • Für Shielded VMs (verschlüsselte VMs unter Hyper-V) wird AES-NI ebenfalls empfohlen.


    Memory:

    Memory:

    Für eine Windows Server Installation mit GUI sollten mindestens 4 GB zur Verfügung stehen. Je mehr Arbeitsspeicher bereit gestellt wird umso besser die Performance. Für Windows Server 2019 Essentials sind 16 GB RAM als Mindestanforderung angegeben, wenn die vollen möglichen 25 Benutzer / 50 Computer mit dem System arbeiten.


    Network:


    Warum VirtIO für Netzwerk in Windows-VMs auf Proxmox?


    1. Höhere Netzwerk-Performance

    • VirtIO ist ein paravirtualisierter Treiber, der direkt mit der Hardware kommuniziert.

    • Geringere CPU-Belastung & weniger Overhead als emulierte Karten.

    • Ermöglicht bis zu 10 Gbit/s Netzwerkgeschwindigkeit, während E1000 oder Realtek oft auf 1 Gbit/s limitiert sind.


    2. Geringerer CPU-Overhead & bessere Effizienz

    • Emulierte Netzwerkkarten (wie Intel E1000) müssen vom Hypervisor übersetzt werden, was zusätzliche CPU-Last erzeugt.

    • VirtIO nutzt direkte Speicherzugriffe (DMA), wodurch weniger CPU-Zyklen für Netzwerk-Traffic benötigt werden.


    3. Bessere Latenz & geringere Paketverluste

    • Besonders für Windows Server mit hoher Netzwerklast (z. B. Dateiserver, Webserver, Datenbanken) geeignet.

    • Unterstützt VirtIO-Net-Features wie Multi-Queue, was die Verarbeitung von Netzwerkpaketen über mehrere CPU-Kerne verteilt.


    4. Unterstützung für moderne Features

    • Jumbo Frames für größere Pakete und bessere Effizienz.

    • VLAN-Tagging und SR-IOV für erweiterte Netzwerkkonfigurationen.

    • Multiqueue-Support, um Netzwerkpakete effizienter über mehrere CPU-Kerne zu verteilen.


    5. Offizieller Treiber von Red Hat für Windows verfügbar

    • Windows benötigt den VirtIO-Netzwerk-Treiber

    • Treiber kann während der Windows-Installation eingebunden oder nachträglich installiert werden.


    Confirm:

    Zum Schluss wird nochmal die Zusammenfassung gezeigt.

    Ggf. „Start after created“..

  • Linux Mint – KVM – Virt-Manager – Einrichten einer virtuellen Netzwerkbrücke

    Linux Mint – KVM – Virt-Manager – Einrichten einer virtuellen Netzwerkbrücke

    Eigentlich hatte ich ja vor, mich im allerersten Beitrag hier auf Bubukiste.de mit meinem Einstieg in die VR-Welt und den ersten Erfahrungen nach dem Kauf der Quest 3 von Meta zu widmen. Oder mit einer Vorstellung dieser Seite und was ich mir dabei gedacht habe, und was für die Zukunft noch geplant ist. Letztlich hat sich nun aber aus verschiedenen Gründen das in der Überschrift genannte Thema in den Vordergrund gedrängt.

    An sich sind die Vorbereitungen für den Betrieb einer KVM auf einem Linux-System kein Hexenwerk. Knackpunkt ist hier aber immer mal wieder die Einrichtung einer virtuellen Netzwerkbrücke, mit dem Ziel, die installierten VMs im lokalen Netzwerk zu betreiben. Standardmäßig läuft der NAT-Modus und das auch einwandfrei. Genauso verhält es sich auch bei der Nutzung von beispielsweise der zu Testzwecken gerne genutzten Virtual Box direkt nach der Installation. Virtual Box ist zwar im Gegensatz zu KVM ein Typ 2 Hypervisor, glänzt dafür aber mit einer Möglichkeit, die Netzwerk-Modi schnell und einfach über die grafische Oberfläche umzustellen. Bei gut ausgestatteten Rechnen und wenn es nur darum geht, mal kurz etwas mit einer einzelnen VM zu testen, ist der Einsatz von Virtual Box oder der VM-Ware Workstation durchaus legitim. Für den permanenten Betrieb mehrerer virtueller Maschinen, und das möglichst effizient, würde ich aber definitiv auf KVM setzen.

    Damit ich es nicht (nochmal) vergesse und nicht irgendwann (wieder einmal) von vorne anfangen muss, und weil ich mir vorstellen kann, dass eine Anleitung hierfür auch anderen zugutekommt, nun die als „Rezept zum Nachkochen“ gezeigte Vorgehensweise, die den Anspruch hat, auch Menschen ohne tiefergehende Linuxkenntnisse die Einrichtung zu ermöglichen.

    Wer sich etwas genauer damit beschäftigen möchte, wodurch sich Typ 1 und Typ 2 Hypervisoren (zu Deutsch Virtualisierer) unterscheiden, und wofür sie idealerweise verwendet werden, bekommt es zum Beispiel hier ganz gut erklärt.

    https://www.computerweekly.com/de/tipp/Vergleich-zwischen-Typ-1-und-Typ-2-Den-richtigen-Hypervisor-auswaehlen

    Die Ausgangssituation für die folgende Anleitung ist ein aktuelles Linux Mint 22.1 (Cinnamon Edition) auf einem x64 System, das die Virtualisierung unterstützt. Auf die notwendigen BIOS-Einstellungen, damit virtualisiert werden kann, gehe ich hier nicht weiter ein. Bitte vorher prüfen. Grob zusammengefasst, für AMD-Prozessoren muss AMD-V und für Intel-Prozessoren muss VT-d verfügbar sein und aktiviert werden. Teilweise hat die Funktion auch einen anderen Namen, der aber in der Regel der Virtualisierung zugeordnet werden kann.


    Anleitung:

    Auf verfügbare Updates prüfen und das System ggf. aktualisieren.

    sudo apt update && sudo apt upgrade -y


    Die benötigten Programme installieren.

    sudo apt install qemu-system-x86 libvirt-daemon-system virtinst virt-manager virt-viewer ovmf swtpm qemu-utils guestfs-tools libosinfo-bin tuned


    Den LibVirt Daemon aktivieren.

    sudo systemctl enable libvirtd.service


    Das System neu starten.

    sudo reboot


    Die Konfiguration prüfen:

    sudo virt-host-validate qemu


    Falls die Meldung kommt das IOMMU deaktiviert ist, muss /etc/default/grub editiert werden. (IOMMU wird unterstützt, ist aber nicht aktiviert)

    nano /etc/default/grub


    Die folgende Zeile hinzufügen bzw. anpassen:

    GRUB_CMDLINE_LINUX="rhgb quiet intel_iommu=on iommu=pt"


    Falls die Meldung kommt „Unknown … Secure Guest support…“.

    Intel CPU >> kann ignoriert werden
    AMD CPU >> https://bugzilla.redhat.com/show_bug.cgi?id=1850351#c5


    Falls Änderungen vorgenommen wurden, GRUB aktualisieren.

    sudo update-grub


    ..ausführen und das System neu starten.

    sudo reboot


    TuneD aktivieren.

    sudo systemctl enable --now tuned


    Das aktive TuneD Profile ausgeben lassen.

    tuned-adm active


    Ggf. das TuneD Profil von „balanced“ auf „virtual-host“ ändern.

    sudo tuned-adm profile virtual-host


    Prüfen, ob die Änderung übernommen wurde.

    tuned-adm active


    Die neue Konfiguration auf Fehler prüfen.

    sudo tuned-adm verify


    Default Network State aktivieren. Hier kommt evtl. die Meldung, dass dies bereits geschehen ist.

    sudo virsh net-start default


    Den automatischen Start aktivieren

    sudo virsh net-autostart default


    Überprüfen

    sudo virsh net-list --all


    NMTUI starten

    nmtui


    Eine Verbindung bearbeiten


    Brücke „Hinzufügen“


    Verbindungstyp „Brücke“ auswählen und „Erstellen“


    Auf „Hinzufügen“


    Neue (Slave) Verbindung Ethernet erstellen


    Verbindung bearbeiten


    Auf IPv4-Konfiguration „Manuall“ umstellen


    Der Brücke über „Anzeigen“ eine feste IP zuweisen


    Netzwerkkonfiguration einstellen


    IPv6 deaktivieren


    OK


    Ethernet-Verbindung löschen


    Löschen


    Zurück


    Beenden

    System neu starten.

    sudo reboot


    Im Virt-Manager kann nun in den Einstellungen für die jeweilige VM die „nm-bridge“ als Netzwerkverbindung eingetragen werden.

    (K)VMs erhalten in den meisten Fällen beim initialen Start nach der Neuinstallation eine IP vom DHCP Server des lokalen Netzwerks zugeteilt. Falls die automatische Adressvergabe per DHCP nicht genutzt werden soll, muss natürlich nachträglich noch in den Netzwerkeinstellungen der laufenden VM eine statische IP eingestellt werden.

    Das geschieht dann in der laufenden VM!!!