Hyper-V – Grundlagen & Verwaltung
Microsofts integrierter Typ-1-Hypervisor: Installation, VM-Erstellung, virtuelle Switches, Checkpoints und PowerShell-Verwaltung fuer Windows Server und Windows 11.
Was ist Hyper-V und wann brauchst du es?
Hyper-V ist Microsofts integrierter Typ-1-Hypervisor – er laeuft direkt auf der Hardware, nicht als Anwendung innerhalb eines Betriebssystems. Das Besondere: Du musst nichts kaufen oder herunterladen. Hyper-V ist bereits in Windows Server 2016/2019/2022/2025 (alle Editionen) sowie in Windows 10/11 Pro und Enterprise enthalten.
Im KMU-Alltag setzt du Hyper-V typischerweise ein, wenn:
- ein physischer Server mehrere Rollen isoliert tragen soll (z.B. Domain Controller + Fileserver + Applikationsserver)
- du Test- oder Entwicklungsumgebungen brauchst, ohne extra Hardware anzuschaffen
- du Disaster Recovery mit Replikation zwischen zwei Standorten abbilden willst
- ein bestehender Server konsolidiert oder ein alter Windows-Server-2008-Klotz als VM weiterbetrieben werden soll
Der Unterschied zu Typ-2-Hypervisoren wie VMware Workstation oder VirtualBox: Hyper-V ist kein Prozess, der auf einem Host-Betriebssystem laeuft. Wenn du Hyper-V aktivierst, wird Windows selbst zur ersten Gastpartition auf dem Hypervisor. Das gibt dir nahezu native Performance fuer VMs.
Voraussetzungen und Systemanforderungen
Bevor du Hyper-V aktivierst, pruefe diese Punkte:
| Anforderung | Detail |
|---|---|
| CPU | 64-Bit-Prozessor mit Hardware-Virtualisierung (Intel VT-x oder AMD-V) |
| SLAT | Second Level Address Translation (Intel EPT oder AMD RVI) – seit 2012er CPUs Standard |
| BIOS/UEFI | Virtualisierung muss im BIOS aktiviert sein (manchmal als “Intel Virtualization Technology” oder “SVM Mode”) |
| RAM | Mindestens 4 GB, empfohlen 16 GB+ fuer produktive Umgebungen |
| Speicher | Schnelle Disks (SSD/NVMe) massgeblich fuer VM-Performance |
| Windows | Server 2016/2019/2022/2025 oder Windows 10/11 Pro/Enterprise (64-Bit) |
Ob dein System SLAT unterstuetzt, pruefst du per PowerShell:
# Systeminfo fuer Virtualisierung pruefen
Get-ComputerInfo -Property "HyperV*"
# Alternativ: systeminfo.exe | findstr /i "hyper-v"
systeminfo | findstr /i "Hyper-V"
Hyper-V aktivieren
Windows 10 / 11 (Client)
# Methode 1: PowerShell (als Administrator)
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
# Methode 2: DISM
DISM /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V
# Neustart danach zwingend erforderlich
Restart-Computer
Alternativ: Win+R → optionalfeatures → Haken bei Hyper-V setzen → OK → Neustart.
Windows Server (Rolle hinzufuegen)
# Hyper-V-Rolle und Verwaltungstools installieren
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
# Nur die PowerShell-Module (fuer Remote-Verwaltung ohne GUI)
Install-WindowsFeature -Name Hyper-V-PowerShell
Hyper-V Manager – die Verwaltungs-GUI
Starte den Hyper-V Manager mit Win+R → virtmgmt.msc oder ueber das Startmenue.
Die wichtigsten Bereiche im Ueberblick:
- Linke Spalte: Liste der Hyper-V-Hosts (lokal und remote)
- Mittleres Fenster: Alle VMs mit Status, CPU-Last und Speicherverbrauch
- Rechte Spalte (Aktionen): Neue VM erstellen, Einstellungen des Hosts, Import/Export
- Unteres Fenster: Details zur ausgewaehlten VM (Checkpoints, Netzwerk, Status)
Fuer Remote-Verwaltung traegst du unter “Mit Server verbinden…” den Hostnamen ein. Das funktioniert auch ohne RDP – du steuerst VMs direkt aus deinem Buero-PC heraus.
Virtuelle Switches – das Netzwerk richtig aufsetzen
Virtuelle Switches sind das Herzstück der Netzwerkverbindung in Hyper-V. Du erstellst sie im Hyper-V Manager unter Aktion > Manager fuer virtuelle Switches. Es gibt drei Typen:
| Switch-Typ | Verbindung | Typischer Einsatz |
|---|---|---|
| Extern | VM hat Zugriff auf physisches Netzwerk | Produktions-VMs, die mit anderen Servern/Clients kommunizieren |
| Intern | VM kommuniziert mit Host und anderen VMs, aber nicht nach aussen | Test-Umgebungen mit Internetzugang ueber den Host (NAT) |
| Privat | Nur VM-zu-VM-Kommunikation, Host ist isoliert | Vollstaendig isolierte Testnetze, Malware-Analyse |
# Externen Switch auf einem Netzwerkadapter erstellen
New-VMSwitch -Name "Extern-LAN" -NetAdapterName "Ethernet" -AllowManagementOS $true
# Internen Switch erstellen
New-VMSwitch -Name "Intern-Test" -SwitchType Internal
# Privaten Switch erstellen
New-VMSwitch -Name "Isoliert-Lab" -SwitchType Private
# Alle Switches anzeigen
Get-VMSwitch | Select-Object Name, SwitchType, NetAdapterInterfaceDescription
Switch Embedded Teaming (SET) und NIC-Teaming
Sobald ein Host mehr als eine physische Netzwerkkarte fuer denselben externen Switch nutzen soll, brauchst du Redundanz und Lastverteilung. Hyper-V bringt dafuer Switch Embedded Teaming (SET) mit – das seit Windows Server 2016 empfohlene Verfahren, weil es Teaming direkt im virtuellen Switch abbildet und dabei RDMA, dynamische VMQ und andere moderne NIC-Features erhaelt, die beim klassischen NIC-Teaming (LBFO, “NIC Teaming”-Rolle) verloren gehen.
# SET-faehigen externen Switch aus zwei physischen NICs erstellen
New-VMSwitch -Name "SET-Extern" -NetAdapterName "NIC1", "NIC2" -EnableEmbeddedTeaming $true
# Aktive Mitglieder eines bestehenden SET-Teams aendern
Set-VMSwitchTeam -Name "SET-Extern" -NetAdapterName "NIC1", "NIC2", "NIC3"
# Team-Konfiguration und Lastverteilungsmodus pruefen
Get-VMSwitchTeam -Name "SET-Extern" | Format-List *
Wichtige Punkte in der Praxis:
- SET unterstuetzt nur die Lastverteilungsmodi Hyper-V Port und Dynamic, kein klassisches LACP-Team – der Switch auf physischer Seite wird ueblicherweise im Modus “Switch Independent” betrieben.
- Alle NICs im SET-Team muessen vom gleichen Hersteller und Treiber sein; gemischte Adaptermodelle werden nicht unterstuetzt.
- Fuer S2D-Cluster (siehe unten) ist SET heute die Standardempfehlung, weil RDMA-Traffic (RoCE oder iWARP) darueber sauber funktioniert.
- Klassisches NIC-Teaming (LBFO) ueber die Windows-Funktion “NIC-Teaming” existiert weiterhin, gilt aber fuer Hyper-V-Switches als veraltet und wird in neueren Windows-Server-Versionen zunehmend zurueckgebaut – fuer neue Hyper-V-Hosts immer SET verwenden.
Neue VM erstellen – Schritt fuer Schritt
Per PowerShell (empfohlen fuer Automatisierung)
# 1. VM erstellen (Generation 2 = UEFI, empfohlen fuer moderne OS)
New-VM `
-Name "SRV-APP01" `
-MemoryStartupBytes 4GB `
-Generation 2 `
-NewVHDPath "D:\VMs\SRV-APP01.vhdx" `
-NewVHDSizeBytes 80GB `
-SwitchName "Extern-LAN"
# 2. Dynamischen Arbeitsspeicher aktivieren
Set-VMMemory -VMName "SRV-APP01" `
-DynamicMemoryEnabled $true `
-MinimumBytes 2GB `
-MaximumBytes 16GB `
-StartupBytes 4GB
# 3. vCPUs zuweisen
Set-VMProcessor -VMName "SRV-APP01" -Count 4
# 4. ISO einlegen (fuer Betriebssystem-Installation)
Add-VMDvdDrive -VMName "SRV-APP01" -Path "C:\ISO\WinSrv2022.iso"
# 5. Boot-Reihenfolge anpassen (Gen 2: DVD als erstes)
$bootOrder = Get-VMFirmware -VMName "SRV-APP01"
Set-VMFirmware -VMName "SRV-APP01" `
-BootOrder ($bootOrder.BootOrder | Sort-Object -Property {$_.BootType -ne "Drive"})
# 6. VM starten
Start-VM -Name "SRV-APP01"
# 7. Verbindung oeffnen
vmconnect localhost "SRV-APP01"
Generation 1 vs. Generation 2
Das ist eine Entscheidung, die du beim Erstellen treffen musst und danach nicht mehr aendern kannst:
| Merkmal | Generation 1 | Generation 2 |
|---|---|---|
| Boot-Firmware | BIOS (Legacy) | UEFI |
| Secure Boot | Nein | Ja (Standard) |
| Performance | Normal | Besser (weniger Emulations-Overhead) |
| Boot-Medien | IDE-Controller, Floppy, PXE (Legacy) | SCSI, PXE (UEFI), USB |
| Unterstuetzte OS | Alles inkl. sehr alte Systeme | Windows 8+ / Server 2012+, moderne Linux-Distros |
| Empfehlung | Nur fuer Legacy-OS (Windows Server 2008, 32-Bit-Systeme) | Immer bevorzugen fuer neue VMs |
VHDX – Virtuelle Festplatten verwalten
Hyper-V nutzt das VHDX-Format (bis 64 TB pro Disk, verbessertes Journal fuer Datensicherheit). Das alte VHD-Format (max. 2 TB) ist nur noch fuer Legacy-Migrationen relevant.
# VHDX dynamisch erstellen (waechst bei Bedarf)
New-VHD -Path "D:\VMs\Daten.vhdx" -Dynamic -SizeBytes 500GB
# VHDX fix (vorab allokiert, bessere Performance)
New-VHD -Path "D:\VMs\Daten-Fix.vhdx" -Fixed -SizeBytes 100GB
# VHDX an bestehende VM anhaengen
Add-VMHardDiskDrive -VMName "SRV-APP01" -Path "D:\VMs\Daten.vhdx"
# Groesse einer bestehenden VHDX erhoehen (VM muss gestoppt sein oder Online-Resize unterstuetzen)
Resize-VHD -Path "D:\VMs\SRV-APP01.vhdx" -SizeBytes 120GB
# VHDX optimieren (ungenutzte Bloecke freigeben bei dynamischen Disks)
Optimize-VHD -Path "D:\VMs\SRV-APP01.vhdx" -Mode Full
# Informationen anzeigen
Get-VHD -Path "D:\VMs\SRV-APP01.vhdx" | Select-Object VhdType, Size, FileSize, MinimumSize
Checkpoints – Sicherheitsnetz vor Aenderungen
Checkpoints (frueher “Snapshots”) speichern den Zustand einer VM zu einem bestimmten Zeitpunkt. Du kannst jederzeit zurueckrollen.
Wichtig: Checkpoints sind kein Ersatz fuer echte Backups. Sie liegen im gleichen Speicherpfad wie die VM – ein Festplattenausfall trifft beides gleichzeitig.
# Checkpoint erstellen (VM kann laufen)
Checkpoint-VM -Name "SRV-APP01" -SnapshotName "Vor Windows-Update 2026-06"
# Alle Checkpoints einer VM anzeigen
Get-VMCheckpoint -VMName "SRV-APP01"
# Zu einem Checkpoint zurueckkehren
Restore-VMCheckpoint -VMName "SRV-APP01" -Name "Vor Windows-Update 2026-06" -Confirm:$false
# Checkpoint loeschen (nach erfolgreichem Test)
Remove-VMCheckpoint -VMName "SRV-APP01" -Name "Vor Windows-Update 2026-06"
Checkpoint-Typen (einstellbar unter VM-Einstellungen > Verwaltung > Prüfpunkttyp):
- Standard-Checkpoint: Speichert RAM-Inhalt + Disk-Zustand. Schnell, aber nicht anwendungskonsistent. Fuer Workstations und Test-VMs gut.
- Produktions-Checkpoint: Nutzt VSS im Gastbetriebssystem fuer konsistente, anwendungssichere Snapshots. Empfohlen fuer Produktions-VMs mit Datenbanken oder Diensten.
Nuetzliche PowerShell-Befehle fuer den Alltag
# Alle VMs und ihren Status anzeigen
Get-VM | Select-Object Name, State, CPUUsage, MemoryAssigned, Uptime
# VM starten / stoppen / neu starten
Start-VM -Name "SRV-APP01"
Stop-VM -Name "SRV-APP01" -Force # Harter Abbruch
Stop-VM -Name "SRV-APP01" -TurnOff # Wie Strom abziehen
Restart-VM -Name "SRV-APP01" -Force
# Graceful Shutdown (benoetigt Integrationsdienste im Gast)
Stop-VM -Name "SRV-APP01"
# VM-Konfiguration anzeigen
Get-VM -Name "SRV-APP01" | Get-VMHardDiskDrive
Get-VMNetworkAdapter -VMName "SRV-APP01"
Get-VMMemory -VMName "SRV-APP01"
# Netzwerkadapter einer VM pruefen
Get-VMNetworkAdapter -VMName "SRV-APP01" | Select-Object Name, MacAddress, SwitchName, IPAddresses
# VM exportieren (fuer Migration oder Backup)
Export-VM -Name "SRV-APP01" -Path "E:\Backup\VMs\"
# VM importieren
Import-VM -Path "E:\Backup\VMs\SRV-APP01\Virtual Machines\*.vmcx"
# Hyper-V Host-Informationen
Get-VMHost | Select-Object Name, LogicalProcessorCount, MemoryCapacity, VirtualHardDiskPath, VirtualMachinePath
Integrationsdienste – die Brücke zwischen Host und Gast
Die Hyper-V Integration Services (IS) sind Treiber und Dienste, die im Gastbetriebssystem laufen und wichtige Funktionen ermoeglichen:
| Dienst | Funktion |
|---|---|
| Heartbeat | Host weiss, ob die VM noch laeuft |
| Datenaustausch (KVP) | Host/Gast tauschen Konfigurationsdaten aus |
| Zeitsynchronisierung | VM-Uhrzeit wird mit dem Host synchronisiert |
| Graceful Shutdown | Sauberes Herunterfahren per Host-Befehl |
| Live Migration | Voraussetzung fuer Memory-Pages-Transfer |
| Backup (VSS) | Produktions-Checkpoints und Host-Level-Backups |
Unter Windows werden die IS automatisch ueber Windows Update aktualisiert. Unter Linux sind die Treiber im Kernel integriert (ab Kernel 3.4+).
# IS-Status aller VMs pruefen
Get-VM | Get-VMIntegrationService | Where-Object {$_.Enabled -eq $false}
# IS fuer eine VM aktivieren
Enable-VMIntegrationService -VMName "SRV-APP01" -Name "Time Synchronization"
Live Migration und Replikation
Live Migration
Live Migration verschiebt eine laufende VM ohne Downtime von einem Hyper-V-Host auf einen anderen. Voraussetzungen:
- Beide Hosts muessen Hyper-V auf gleicher oder kompatibler CPU-Generation laufen
- Gemeinsamer Speicher (Shared Storage via SMB 3.0, iSCSI oder FC) oder Shared-Nothing Live Migration (VM-Storage wird mitmigriert)
- Delegierung in Active Directory fuer Kerberos oder CredSSP konfiguriert
# Live Migration vorbereiten (auf Quell-Host)
Enable-VMMigration -ComputerName "HVHOST01"
Set-VMMigrationNetwork -ComputerName "HVHOST01" -Subnet "10.10.10.0/24"
# VM zu Ziel-Host migrieren
Move-VM -Name "SRV-APP01" -DestinationHost "HVHOST02" -IncludeStorage -DestinationStoragePath "D:\VMs\"
# Vor Migration Kompatibilitaet pruefen
Compare-VM -Name "SRV-APP01" -DestinationHost "HVHOST02"
Hyper-V Replikation
Fuer Disaster Recovery ohne teures SAN: Hyper-V Replikation repliziert VMs asynchron auf einen zweiten Host (auch WAN-tauglich).
# Replikation aktivieren (Ziel-Host)
Set-VMReplicationServer -ReplicationEnabled $true -AllowedAuthenticationType Kerberos -ReplicationAllowedFromAnyServer $true
# VM fuer Replikation konfigurieren (Quell-Host)
Enable-VMReplication -VMName "SRV-APP01" -ReplicaServerName "HVHOST-DR" -ReplicaServerPort 80 -AuthenticationType Kerberos -CompressionEnabled $true
# Erste Replikation starten
Start-VMInitialReplication -VMName "SRV-APP01"
# Replikationsstatus anzeigen
Get-VMReplication -VMName "SRV-APP01"
Hyper-V Failover Clustering – CSV, Shared VHD Set und Quorum
Live Migration und Replikation reichen fuer viele Szenarien, aber sobald du echte Hochverfuegbarkeit brauchst (automatisches Failover, wenn ein Host komplett ausfaellt), kommst du um Failover Clustering nicht herum. Ein Hyper-V-Cluster besteht aus mehreren Hosts (Nodes), die gemeinsamen Speicher nutzen und VMs bei Bedarf automatisch auf einen anderen Node verschieben.
Drei Bausteine sind dabei Hyper-V-spezifisch:
- Cluster Shared Volumes (CSV): Ein gemeinsames NTFS/ReFS-Volume, auf das gleichzeitig alle Cluster-Nodes lesend und schreibend zugreifen koennen. VHDX-Dateien liegen auf einem CSV, damit eine VM ohne Storage-Umkopieren von Node zu Node wandern kann. Erkennbar am Pfad
C:\ClusterStorage\Volume1\.... - Shared VHD Set (.vhds): Erlaubt es, eine einzelne virtuelle Festplatte gleichzeitig an mehrere VMs anzuhaengen – zum Beispiel fuer einen Gast-Cluster (Failover-Cluster innerhalb von VMs, etwa fuer SQL Server oder Fileserver-Rollen), der sich ein gemeinsames Quorum- oder Datenlaufwerk teilt.
- Quorum: Entscheidet, wie viele Node-Ausfaelle der Cluster verkraftet, bevor er sich selbst abschaltet (Split-Brain-Schutz). Bei geraden Node-Zahlen wird meist eine Cloud Witness oder ein Dateifreigabe-Zeuge als zusaetzliche Stimme eingebunden.
# Cluster mit zwei Hyper-V-Hosts erstellen (auf einem der Nodes ausfuehren)
New-Cluster -Name "HV-CLUSTER01" -Node "HVHOST01", "HVHOST02" -StaticAddress 10.10.10.50
# Freigegebenen Datentraeger als Cluster Shared Volume hinzufuegen
Add-ClusterSharedVolume -Name "Cluster Disk 1"
# Cloud Witness als Quorum-Zeuge konfigurieren (Azure Storage Account noetig)
Set-ClusterQuorum -CloudWitness -AccountName "meinstorageaccount" -AccessKey "<Key>"
# VM-Rolle im Cluster hochverfuegbar machen
Add-ClusterVirtualMachineRole -VMName "SRV-APP01"
Storage Spaces Direct (S2D) – hyperkonvergente Hyper-V-Cluster
Statt ein klassisches SAN als gemeinsamen Speicher an den Cluster anzubinden, kannst du mit Storage Spaces Direct (S2D) den lokalen Storage (SSD/NVMe/HDD) jedes Hosts buendeln und daraus einen verteilten, redundanten Speicherpool bilden. Das Ergebnis ist eine hyperkonvergente Infrastruktur (HCI): Rechenleistung und Storage laufen auf denselben Hosts, ganz ohne separates SAN.
| Aspekt | Detail |
|---|---|
| Minimum Nodes | 2 Nodes (nur Zwei-Wege-Spiegelung moeglich), 3 Nodes fuer Drei-Wege-Spiegelung, 4+ fuer Erasure Coding (Parity) |
| Edition | Windows Server Datacenter auf allen Nodes zwingend, keine gemischten Editionen |
| Netzwerk | Mindestens 2 RDMA-faehige NICs pro Node (RoCEv2 oder iWARP), meist ueber ein SET-Team gebuendelt |
| Hardware | Nodes sollten identisch oder sehr aehnlich sein (CPU-Generation, RAM, Disks) – zertifizierte Hardware via “Windows Server Software-Defined”-Katalog |
| Datentraeger | Mix aus NVMe (Cache) und SSD/HDD (Kapazitaet) moeglich, automatisches Tiering |
# Voraussetzung pruefen: Cluster existiert bereits, Disks sind auf allen Nodes sichtbar
Test-Cluster -Node "HVHOST01", "HVHOST02", "HVHOST03", "HVHOST04" -Include "Storage Spaces Direct", "Inventory", "Network"
# S2D auf dem bestehenden Cluster aktivieren
Enable-ClusterStorageSpacesDirect -PoolFriendlyName "S2D-Pool01"
# Volume mit Drei-Wege-Spiegelung erstellen
New-Volume -StoragePoolFriendlyName "S2D-Pool01" -FriendlyName "S2D-Volume01" `
-FileSystem CSVFS_ReFS -Size 2TB -ResiliencySettingName Mirror
# Status des Speicherpools und der Laufwerke pruefen
Get-StoragePool -FriendlyName "S2D-Pool01" | Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus
Shielded VMs, Host Guardian Service und Virtualization-Based Security
In Umgebungen mit hohen Compliance-Anforderungen (z.B. Hosting bei einem Provider, dessen Admins nicht in die VM-Inhalte einsehen koennen sollen) reicht normale VM-Sicherheit oft nicht aus. Ein Fabric-Administrator mit Zugriff auf den Hyper-V-Host kann sonst jederzeit eine VHDX kopieren und offline auslesen. Shielded VMs loesen genau dieses Problem:
- Die VM-Festplatte wird per BitLocker verschluesselt, der Schluessel liegt nicht auf dem Host.
- Ein virtuelles TPM (vTPM) sichert Boot-Integritaet und Schluesselverwaltung innerhalb der VM ab.
- Konsolenzugriff (VMConnect) auf eine voll geschuetzte Shielded VM ist fuer den Fabric-Admin gesperrt – nur RDP/WinRM in die VM hinein funktioniert noch.
- Der Host Guardian Service (HGS) ist die zentrale Vertrauensstelle: Er prueft per Attestierung (TPM-basiert oder Admin-vertrauensbasiert), ob ein Host “gesund” und autorisiert ist, bevor er den Schluessel zum Entsperren einer Shielded VM herausgibt.
# Auf dem HGS-Server: Guardian (Vertrauensanker) fuer den Fabric-Besitzer erstellen
$Owner = New-HgsGuardian -Name "Fabric-Owner" -GenerateCertificates
# Guardian-Metadaten auf den Hyper-V-Host importieren
$Guardian = Import-HgsGuardian -Path "C:\HGS\FabricOwner.xml" -Name "Fabric-Owner" -AllowUntrustedRoot
# Key Protector fuer eine konkrete VM erzeugen
$KeyProtector = New-HgsKeyProtector -Owner $Owner -Guardian $Guardian -AllowUntrustedRoot
# VM stoppen, Key Protector zuweisen, Shielding und vTPM aktivieren
Stop-VM -Name "SRV-SENSIBEL01"
Set-VMKeyProtector -VMName "SRV-SENSIBEL01" -KeyProtector $KeyProtector.RawData
Set-VMSecurityPolicy -VMName "SRV-SENSIBEL01" -Shielded $true
Enable-VMTPM -VMName "SRV-SENSIBEL01"
Technisch aufgebaut ist das Ganze auf Virtualization-Based Security (VBS): Windows nutzt den Hypervisor, um sicherheitskritische Prozesse (etwa den LSA-Prozess fuer Credential Guard oder den Hypervisor-Code-Integritaetsdienst HVCI) in einer isolierten, vom normalen Betriebssystem-Kernel getrennten Speicher-Enklave laufen zu lassen. Selbst wenn der Windows-Kernel kompromittiert wird, bleiben diese Enklaven geschuetzt. VBS ist auch fuer Standard-Workstations relevant, nicht nur fuer Hyper-V-Hosts – Details dazu im Kontext von Endpoint-Haerte findest du unter IT-Security-Grundlagen fuer KMU.
Performance-Tuning: NUMA-Spanning und Prozessor-Kompatibilitaetsmodus
Auf Hosts mit mehreren physischen CPU-Sockeln (Multi-Socket-Server) ist der Arbeitsspeicher in NUMA-Knoten (Non-Uniform Memory Access) aufgeteilt: Jeder Prozessor-Sockel hat “seinen” lokalen RAM, auf den er schneller zugreifen kann als auf den RAM eines anderen Sockels. Fuer speicherhungrige VMs (grosse SQL-Server-Instanzen, Terminalserver mit vielen Sitzungen) ist das relevant.
- NUMA-Spanning (Standard: aktiviert) erlaubt einer VM, RAM ueber mehrere physische NUMA-Knoten hinweg zu belegen, wenn sie groesser ist als ein einzelner Knoten. Das laesst die VM zwar problemlos starten, kann aber die Performance messbar senken, weil Speicherzugriffe teils ueber den langsameren Cross-Node-Pfad laufen.
- Deaktivierst du NUMA-Spanning, startet, live-migriert oder restauriert Hyper-V eine VM nur noch dann, wenn ihr virtueller NUMA-Knoten komplett in einen physischen Knoten passt – dafuer ist die erreichbare Performance vorhersagbarer.
# NUMA-Spanning auf Host-Ebene deaktivieren (fuer maximale NUMA-Lokalitaet)
Set-VMHost -NumaSpanningEnabled $false
# Virtuelle NUMA-Topologie einer VM gezielt setzen
Set-VMProcessor -VMName "SRV-SQL01" -MaximumCountPerNumaNode 8
# NUMA-Konfiguration einer VM anzeigen
Get-VMProcessor -VMName "SRV-SQL01" | Select-Object MaximumCountPerNumaNode, MaximumCountPerNumaSocket
Ein zweites Tuning-Thema betrifft Live Migration zwischen Hosts mit unterschiedlichen CPU-Generationen (z.B. aeltere und neuere Intel-Generation im selben Cluster). Ohne Anpassung schlaegt die Migration fehl, weil die Ziel-CPU nicht alle Instruktionssaetze der Quelle bietet. Der Prozessor-Kompatibilitaetsmodus loest das, indem er der VM nur den kleinsten gemeinsamen Instruktionssatz aller Cluster-Hosts zeigt:
# Prozessor-Kompatibilitaetsmodus fuer Live Migration aktivieren (VM muss gestoppt sein)
Stop-VM -Name "SRV-APP01"
Set-VMProcessor -VMName "SRV-APP01" -CompatibilityForMigrationEnabled $true
Start-VM -Name "SRV-APP01"
Windows Admin Center – moderne GUI fuer Hyper-V
Der klassische Hyper-V Manager (virtmgmt.msc) reicht fuer Einzel-Hosts, stoesst aber bei Clustern, S2D-Uebersicht oder browserbasiertem Zugriff an Grenzen. Windows Admin Center (WAC) ist Microsofts kostenlose, browserbasierte Verwaltungskonsole und mittlerweile die empfohlene GUI fuer alles rund um Hyper-V, Cluster und hyperkonvergente Infrastruktur.
- Installation: Kleine MSI-Datei, entweder im Desktop-Modus auf einem Windows-10/11-Client (fuer den schnellen Einstieg) oder im Gateway-Modus als Dienst auf einem Windows Server (fuer produktiven Mehrbenutzer-Zugriff).
- Funktionsumfang fuer Hyper-V: VMs erstellen, starten, live migrieren, Checkpoints verwalten, virtuelle Switches konfigurieren – alles per Web-UI, inklusive grafischer Performance-Uebersicht.
- Cluster- und S2D-Ansicht: Zeigt Cluster-Health, CSV-Belegung und Storage-Pool-Status hyperkonvergenter Cluster uebersichtlich an, ohne dass du jeden Node einzeln per PowerShell abfragen musst.
- Erweiterbar: Ueber Extensions lassen sich zusaetzliche Funktionen (Azure-Integration, Backup-Anbieter, Monitoring) nachruesten.
# Windows Admin Center Gateway unbeaufsichtigt installieren (Server-Variante)
msiexec /i WindowsAdminCenter.msi /qn /L*v log.txt SME_PORT=443 SSL_CERTIFICATE_OPTION=generate
# Hyper-V-Host im Admin Center per PowerShell als Extension nachinstallieren (falls noetig)
Install-Module -Name PowerShellGet -Force
Fuer reine Ad-hoc-Aufgaben auf einem einzelnen Host bleibt der Hyper-V Manager weiterhin ausreichend; sobald mehrere Hosts, ein Cluster oder S2D im Spiel sind, spart Windows Admin Center gegenueber reinem PowerShell-Handbetrieb deutlich Zeit.
Troubleshooting – haeufige Probleme
VM startet nicht nach Checkpoint-Wiederherstellung Oft ist die AVHDX-Kette unterbrochen. Im Hyper-V Manager: Rechtsklick auf VM > Datentraeger zusammenfuehren. Alternativ:
# Checkpoints zusammenfuehren (Merge)
Merge-VHD -Path "D:\VMs\SRV-APP01_12345.avhdx" -DestinationPath "D:\VMs\SRV-APP01.vhdx"
VM haengt im Status “Gespeichert” fest
# Gespeicherten Zustand verwerfen und VM neu starten
Stop-VM -Name "SRV-APP01" -TurnOff
Start-VM -Name "SRV-APP01"
Netzwerk in VM nicht erreichbar Pruefe in dieser Reihenfolge:
- Switch-Zuordnung der VM:
Get-VMNetworkAdapter -VMName "SRV-APP01" - Ist der physische Adapter des externen Switches aktiv?
Get-NetAdapter - Hat die VM die Integrationsdienste installiert (Netzwerktreiber)?
- Gibt es einen Konflikt mit der Windows Firewall des Hosts? Siehe Windows Firewall – Konfiguration
Hyper-V-Dienst startet nicht
# Hyper-V-Dienste ueberpruefen
Get-Service -Name "vmms", "nvspwmi" | Select-Object Name, Status
# Neustart der Hyper-V Virtual Machine Management
Restart-Service -Name "vmms" -Force
Schlechte VM-Performance
- Dynamischer RAM: Mindest-RAM zu tief gesetzt – VM swappt ins VHDX
- VHDX-Datei auf einer Netzwerkfreigabe statt lokalem Storage → auf lokale SSD verschieben
- Zu viele Checkpoints aktiv → zusammenfuehren oder loeschen
- vCPU-Uebersubskription: Mehr vCPUs vergeben als physische Kerne vorhanden
Hyper-V und PowerShell-Scripting im KMU-Alltag
Typische Automatisierungsaufgaben, die du per Script loesen kannst:
# Taeglich: Alle VMs mit ihrem Snapshot-Status und Disk-Belegung ausgeben
Get-VM | ForEach-Object {
$vm = $_
$checkpoints = (Get-VMCheckpoint -VMName $vm.Name).Count
$disks = Get-VMHardDiskDrive -VMName $vm.Name
$totalSize = ($disks | ForEach-Object { (Get-VHD $_.Path).FileSize }) | Measure-Object -Sum
[PSCustomObject]@{
Name = $vm.Name
Status = $vm.State
Checkpoints = $checkpoints
DiskGB = [math]::Round($totalSize.Sum / 1GB, 1)
}
} | Format-Table -AutoSize
# Alle gestoppten VMs starten
Get-VM | Where-Object { $_.State -eq "Off" } | Start-VM
# VM-Speicherpfad auf neue Disk verschieben (VM gestoppt)
Move-VMStorage -VMName "SRV-APP01" -DestinationStoragePath "E:\VMs\"
Mehr Ideen fuer PowerShell-Scripting im Alltag findest du unter PowerShell im IT-Alltag.
Weiterlernen
- Hyper-V unter Windows Server – Microsoft Learn (Deutsch)
- Erstellen einer VM in Hyper-V – Microsoft Learn
- Arbeiten mit Hyper-V und PowerShell – Microsoft Learn
- Hyper-V Netzwerkplanung – Microsoft Learn
- Systemanforderungen fuer Hyper-V – Microsoft Learn
- Hyper-V Replikation einrichten – Microsoft Learn
- Storage Spaces Direct – Uebersicht – Microsoft Learn
- Guarded Fabric und Shielded VMs – Microsoft Learn
- Prozessor-Kompatibilitaetsmodus konfigurieren – Microsoft Learn
- Windows Admin Center – Installation – Microsoft Learn
Videos
Kommentare
Frage, Verbesserungsvorschlag oder eigene Erfahrung zu diesem Artikel? Schreib einen Kommentar. Neue Beiträge erscheinen nach kurzer Moderation.
- Lade Kommentare …