Nested Virtualization in Azure

Unter Azure wird als bald möglich sein nested virtualization zu nutzen (Nähere Infos). Nested Virtualization ist ein Features das lange Zeit nur VMware Kunden vorbehalten war.
Mit der Einführung von Server 2016 war es nun auch Kunden, die Windows Server 2016 als Hypervisor nutzen, möglich Nested Virtualization zu nutzen. Vereinfacht ausgedrückt hat man die Möglichkeit mit Hilfe von Nested Virtualization einen funktionsfähigen Hypervisor innerhalb einer VM auszuführen. Aktiveieren lässt sich das Feature pro VM über die Powershell: set-vmprocessor -vmname "myserver"
-exposevirtualizationextensions $true

Wer Lust und Zeit hat könnte so z.B. (mit kleinen Anpassungen) einen ESXi Server unter Hyper-V betreiben. Das wäre sogar mit auf einem Windows 10 möglich und ist nicht nur rein auf Windows Server berschränkt. Nested Virtualization wird allerdings nicht für produktive Umgebungen empfohlen. Doch warum unterstützt Microsoft dann überhaupt Nested Virtualization?

 

 Nested

Der Grund heißt schlicht und einfach: Container. Vorreiter dieser Technologie ist Docker. Doch Docker war früher unter Windows nicht nutzbar. Geschweige denn, dass ein Windows Admin schon einmal etwas davon gehört hätte. Damit sich das ändert, sind Docker und Microsoft für Windows Server 2016 eine Partnerschaft eingegangen.
Microsoft bietet aktuell zwei verschiedene Arten von Container mit Windows Server 2016 an:

  • Windows Container
  • Hyper-V Container (worin der Grund für Nested Virtualization liegt)

Doch was ist eigentlich ein Container? Container

Im Grunde ist ein Container ein isolierter Ort, an dem eine Anwendung ohne Beeinflussung der Ressourcen anderer Container oder des Hosts ausgeführt werden kann.
Eine VM besteht klassisch aus einer emulierten Hardware, dem Betriebssystem und Applikation. Ein Host, der drei Windows Server 2012 VMs ausführt muss also für jede VM den Overhead durch die Hardwarevirtualisierung und das Batriebssystem tragen. Das kostet Ressourcen und Performance.
Im Unterschied dazu läuft auf einem Server mit drei containerisierten Applikationen nur ein Betriebssystem, das sich alle drei Container teilen.
Die von allen dreien genutzten Teile des Betriebssystems werden nur einmal gelesen, dazu hat jeder Container individuelle Zugriffsrechte auf das Betriebssystem.
Dadurch sind Container sehr viel "leichter" als virtuelle Maschinen und benötigen weniger Ressourcen. Hängen aber auch von dem darunterliegenden OS ab. Das kostet Flexibilität, da man mit Containern natürlich kein Windows auf einen Linux-Server kriegt. Wohingegen ich eine VM recht leicht von 2016 auf 2012 oder gar VM transportieren könnte.
Ganzheitlich betrachtet offerieren Container generell auch nicht denselben Level an Isolation wie man das von der klassichen Hadware-Virtualisierung gewohnt ist. Schließlich laufen alle Container auf demselben Kernel, nämlich dem des Host-Systems.
Hyper-V-Container bieten hier eine höhere Isolationsstufe. Hyper-V Container funktionieren erst einmal ähnlich wie Windows Server Container, legen aber zusätzlich eine Hyper-V Schicht unter die Applikation, was eine bessere Isolation der Anwendungen ermöglich. Der Container läuft hierbei in einer speziellen VM weshalb hier auch, anders als bei Windows Containern, die Nested Virtualization benötigt wird. So ist eine Isolierung des Kernels zwischen den Containern und auch zu dem Host-OS gewährleistet. Sinnvoll nutzbar ist das zum Beispiel mit einem „Nano“-Server.

Doch zurück zu Nested Virtualization auf Azure und Windows Server 2016. Was bringt mir das? Wie gesagt kann ich so Hyper-V Container innerhalb von VMs nutzen und ich habe die Möglichkeit Testumgebungen aufzusetzen die einen Hypervisor verlangen. So werden wir bald die Möglichkeit haben in Azure Testumgebungen aufzusetzen um beispielsweise die Azure Site Recovery Services testen zu können.

  • Erstellt am .
Copyright by Orange Networks GmbH