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, ohne dafür physische Hardware zu benötigen.
Nested Virtualization kann hilfreich sein, um einfach nur eine Virtualisierungslösung zu testen und sich mit dieser Lösung vertraut zu machen, oder für folgenden Anwendungsfall: Im nachfolgenden Beispiel soll eine Insider Preview des kommenden Windows Servers innerhalb von Azure ausgeführt werden. Zwar findet sich die Insider Preview vom Windows Server vNext auch als Image im Azure-Marketplace. Man kann sie aber nur nutzen, wenn das Konto, mit dem man an Azure angemeldet ist, auch für das Insider Preview Programm registriert ist. Folgt man der Empfehlung, produktiv und zum Testen genutzte Konten zu trennen, ist das Image ohne eine separate Anmeldung an Azure daher nicht direkt nutzbar. Hier hilft die Nested Virtualization. Bei der Einrichtung einer neuen VM als Basis in Azure sind folgende Punkte zu beachten:
Beim Sicherheitstyp ist "Standard" die richtige Wahl:
Weiterhin muss die Größe bzw. der Typ der VM Nested Virtualization unterstützen. Hier hilft ein Blick in das Verzeichnis der VMs in der Azure-Online-Dokumentation, wo z. B. für Maschinen der Serien Dv3 und Dsv3 sowie auch die Serien Dv4 und Dsv4 Nested Virtualization als "supported" aufgeführt ist.
Ist die Maschine fertig eingerichtet, wird Hyper-V mit folgendem PowerShell-Kommando installiert.
Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart
Wurde beim Einrichten der VM der falsche Sicherheitstyp oder eine Größe ohne Support für Nested Virtualization gewählt, schlägt das Kommando fehl:
Sofern die Voraussetzungen erfüllt sind, läuft der PowerShell-Befehl durch:
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, im vorliegenden Beispiel 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
Eine neue Maschine, hier installiert mithilfe des ISO-Images der Insider Preview vom Windows Server vNext, aka Windows Server 2025, wird nun 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 auch vom Host aus per Remote Desktop Protocol (RDP) erreichbar.