Das Geheimnis der VM-Version in Hyper-V

Seit Windows Server 2012 R2 zeigt der Hyper-V-Manager für alle virtuellen Maschinen im Infobereich ein Feld “Version” an, das es vorher dort nicht gab. Das Feld ist ausgesprochen langweilig, denn es steht immer die Version 5.0 dabei. Was hat es damit auf sich?

Seit der Betaphase von Hyper-V (endete mit Windows Server 2008) entwickelt Microsoft das Format von virtuellen Maschinen in Hyper-V immer weiter. Es handelt sich dabei weniger um die Spezifikation der virtuellen Hardware, die eine VM vom Host präsentiert bekommt, sondern um eine ganze Reihe technischer Detaileinstellungen, die für eine VM gelten. Diese Version hat sich bislang von Hyper-V-Version zu Hyper-V-Version weiterentwickelt. In Windows Server 2012 R2 hat sie eben die Nummer 5.0, die das Managementprogramm anzeigt. Die Nachfolgeversion (derzeit unter dem Namen “Windows Server Technical Preview” vorab zu testen) wird die Nummer 6.0 verwenden.

Auch in der PowerSell lässt sich die VM-Version ausgeben

VMs verschiedener Versionen sind zueinander inkompatibel. Das wirkt sich bislang allerdings immer nur in einer Richtung aus: Verschiebt man eine vorhandene VM von einem Hyper-V-Host auf einen anderen Host, der eine neuere Windows-Server-Version ausführt, so aktualisiert Hyper-V die VM. Dadurch wird diese mit dem neuen Hypervisor kompatibel. Zurück geht es dann aber nicht mehr: Eine so konvertierte VM kann man nicht wieder auf den älteren Host zurück übertragen. (Anmerkung: Bis einschließlich Windows Server 2012 konnte man dieses Verschieben nur durch Export und Import bwerkstelligen. Erst seit Windows Server 2012 R2 geht das auch per Live Migration – aber eben nur von einem 2012-Host zu einem 2012-R2-Host, nicht umgekehrt.)

Da diese Konvertierung vom Hypervisor automatisch ausgeführt wurde, konnte der Administrator auch keinen Einfluss darauf nehmen. Daher gab es bislang keinen Grund, die Versionsnummer einer VM überhaupt anzuzeigen – es war nur ein internes technisches Detail. Mit der nächsten Hyper-V-Version wird sich das allerdings ändern.

Künftig wird Hyper-V eine VM, die von einem Host mit der Vorgängerversion von Hyper-V aus verschoben wurde, nicht mehr automatisch konvertieren. Ein spezieller Kompatibilitätsmodus sorgt dafür, dass Hyper-V auch solche “älteten” VMs betreiben kann. In diesem Fall kann man eine solche VM dann auch wieder auf den älteren Host zurückschieben – ob das per Live Migration oder per Export/Import geschieht, ändert daran nichts. Erst wenn man die betreffende VM ausdrücklich konvertiert (geht derzeit nur per PowerShell – aber das kann sich bis zum Erscheinen der neuen Server-Version noch ändern), gibt es keinen Weg mehr zurück. Allerdings kann diese VM auch erst dann die neuen Features der aktuellen Hypervisor-Version nutzen.

Windows Server Technical Preview nutzt für neue VMs die Version 6.0

Diese Änderung im Vorgehen ermöglicht nicht nur mehr Flexibilität für den Administrator. Vor allem war sie technisch notwendig geworden, weil Microsoft mit der nächsten Fassung von Windows Server (endlich) das schrittweise Aktualisieren von Hosts in einem Cluster ermöglichen wird. Dieses so genannte “Rolling Upgrade” sieht vor, dass man in einem Hyper-V-Cluster aus mehreren Hosts zunächst einen einzelnen Host auf die neue Windows-Server-Version aktualisiert. Der Cluster läuft dann im Mischbetrieb aus alter und neuer Version; VMs kann man hin- und herschieben. Dann kann man schrittweise auch die weiteren Hosts updaten, bis der ganze Cluster nur noch aus Hosts der neuen Version besteht. Am Ende konvertiert man die VMs und schaltet den Cluster in einen “einheitlichen Modus”, in dem er dann alle neuen Features nutzen kann.

So erklärt sich auch, dass bereits der Hyper-V-Manager von Windows Server 2012 R2 die Versionsnummer anzeigt: Windows Server 2012 R2 ist die erste Version, die (gemeinsam mit dem Nachfolge-Windows) gewissermaßen als “Quell-Server” dieses “Rolling Upgrade” unterstützen wird. Daher muss man dort natürlich auch die VM-Version anzeigen können. Einen praktischen Sinn erhält diese Information allerdings erst, wenn das nächste Server-Windows erscheint und man beginnen kann, einzelne Hosts in einem bestehenden Cluster zu aktualisieren.