Mit verschachtelter Virtualisierung, im Englischen "Nested Virtualization", ist es möglich, einen Hypervisor auf einem anderen Hypervisor auszuführen. So lässt sich etwa eine Testumgebung für Microsoft Hyper-V innerhalb von Microsoft Azure aufbauen – in Verbindung mit dem Microsoft Windows Server 2025 allerdings derzeit nur mit Workaround.
Bereits im letzten Jahr hatte ich mich in einem Beitrag damit beschäftigt, wie man mithilfe von Microsoft Windows Server 2022 und der Hyper-V-Rolle per verschachtelter Virtualisierung eine Testumgebung in der Azure-Cloud konfigurieren kann. Nachdem der Nachfolger Windows Server 2025 nun schon über ein halbes Jahr auf dem Markt ist, lag es eigentlich nahe, diesen in gleicher Weise zu verwenden. Leider stellte sich aber heraus, dass dies Stand heute nicht ohne Weiteres funktioniert.
Folgt man der früheren Anleitung und erstellt eine passende VM in Azure (Sicherheitstyp "Standard" und eine Größe der Serien Dv3 und Dsv3 oder auch der Serien Dv4 und Dsv4, für die Nested Virtualization als "supported" aufgeführt ist), verwendet dann aber als Image "Windows Server 2025 Datacenter: Azure Edition – x64 Gen2", so schlägt das PowerShell-Kommando zur Installation von Hyper-V
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
mit der nachstehenden Meldung fehl:
Der Beitrag eines Nutzers in Microsofts Techcommunity deutet darauf hin, dass dieses Problem auch in Verbindung mit lokalen Installation von Hyper-V auftritt. Und in einem weiteren Beitrag beschreibt derselbe Nutzer, dass das Problem offenbar nur in Verbindung mit Instanzen von Windows Server 2025 auftritt, die mit der grafischen Benutzeroberfläche (Desktopdarstellung) installiert sind, bei Core-Installationen ohne GUI aber nicht.
Auch für ein Setup in Azure konnte ich dieses Verhalten nachvollziehen. Verfügt der Server über die Desktopdarstellung, funktioniert die Installation von Hyper-V nicht. Als Workarounds bieten sich nur die Verwendung von Windows Server 2022 oder aber der Windows Server 2025 ohne GUI, also die Auswahl eines Images wie "Windows Server 2025 Datacenter: Azure Edition Core – x64 Gen2" oder "Windows Server 2025 Datacenter Server Core – x64 Gen2":
Ist eine solche Maschine fertig eingerichtet, läuft der PowerShell-Befehl zur Installation von Hyper-V durch:
Auch die übrigen Befehle aus dem früheren Beitrag funktionieren. Nach einem obligatorischen Neustart legt das folgende PowerShell-Kommando einen neuen virtuellen Switch an, über den künftige VMs auf Hyper-V-Basis ins Internet kommunizieren können:
New-VMSwitch -Name "InternalNATSwitch" -SwitchType Internal
Das PowerShell-Kommando...
Get-NetAdapter
...verrät uns den Interface-Index des neuen Adapters, z. B. die 13. Diese benötigt das folgende Kommando, um dem Switch eine NAT-IP-Adresse zuzuweisen:
New-NetIPAddress -IPAddress 192.168.0.1 -PrefixLength 24 -InterfaceIndex 13
Zu guter Letzt konfiguriert das folgende Kommando dazu das passende interne Netzwerk:
New-NetNat -Name "InternalNat" -InternalIPInterfaceAddressPrefix 192.168.0.0/24
Wer nun den Hyper-V-Host mit den grafischen Hilfsmitteln administrieren möchte, benötigt ein weiteres System mit Desktopdarstellung und installiert dort die Verwaltungswerkzeuge:
Anschließend nimmt der grafische Hyper-V-Manager mit dem Host Kontakt auf. Eine neue Maschine wird dann in Hyper-V zur Verwendung des neuen virtuellen Switches konfiguriert und benötigt anschließend innerhalb des virtuellen Betriebssystems noch eine manuelle Konfiguration der IP-Einstellungen mit einer IP-Adresse im passenden Netz sowie der Adresse des Switches als Gateway. Nun kann die VM über den Switch und das Netzwerk der Host-Maschine das Internet erreichen und ist aus dem Netzwerk per Remote Desktop Protocol (RDP) erreichbar.
Wer darüberhinaus noch weitere Einstellungen des Hosts grafisch steuern möchte, etwa über die "Computerverwaltung", konfiguriert dazu noch die Firewall des Hosts entsprechend, wahlweise mittels Gruppenrichtlinien oder lokal per PowerShell:
New-NetFirewallRule -DisplayName "Allow RPC" -Direction Inbound -Protocol TCP -LocalPort 135 -Action Allow
New-NetFirewallRule -DisplayName "Allow Dynamic RPC" -Direction Inbound -Protocol TCP -LocalPort 49152-65535 -Action Allow
Get-NetFirewallRule | Where-Object { $_.DisplayGroup -eq "Remote Event Log Management" } | Enable-NetFirewallRule
So lässt sich auch der Windows Server 2025 zur Mitarbeit überreden.