Hyper-V 2019 – ist das wirklich RTM?

Nach dem ruppigen (Fehl-)Start von Microsoft Windows Server 2019 lag es nun auch an mir, einem Kunden einen nagelneuen Hypervisor mit besagtem Betriebssystem zu installieren. Als Hardwarebasis diente ein HPE ML350 Gen 10.

Der eingesetzte Server: Keine exotische Kombination

Vorbereitungen

Installiert wurde das Betriebssystem (Windows Server 2019 Standard) via Smart Provisioning, direkt nach Installation des Betriebssystems wurde das aktuellste Servicepack for Proliant installiert – wir haben in der Vergangenheit ja gelernt, wie Windows-eigene Treiber bisweilen so arbeiten.

Wer braucht schon eine Anzeige

Die erste Überraschung: Wenn der physikalisch angeschlossene Bildschirm erst einmal energiesparenderweise abgeschaltet wurde, kommt das Bild konsequenterweise nicht wieder! Auch über iLO: blank Screen. Lediglich via RDP kann man wieder am System arbeiten. Das ist schon… hässlich. Ob es sich hier um ein HP-Problem handelt oder ein Server 2019-Problem, kann noch nicht abschließend gesagt werden.

Virtueller Switch mit Hindernissen

Die nächste unangenehme Überraschung dann beim Anlegen eines virtuellen Switches: Fehler, Ressource nicht gefunden, ätsch! Habe ich schon erwähnt, dass ich keine Beta, sondern ein komplett gepatches RTM konfiguriere? Und ich frage mich hinsichtlich dieser Basisfunktionlität: Hyper-V 2019 – ist das wirklich RTM?
Im Rahmen einer schnellen Recherche konnte festgestellt werden, dass es offensichtlich doch Treiberprobleme gibt, und unbedingt die Originalen Intel Treiber für den HPE 4-Port 369i Adapter verwendet werden sollen. Ob man danach die Hyper-V Rolle neu installieren sollte, darüber streitet sich die Community, ich habe reinstalliert.

Tatsächlich kann man danach auch schon fast den virtuellen Switch anlegen. In meinem Fall aber ließ sich NIC #4 nicht mehr zu einem virtuellen Switch hinzufügen, weil sie es schon sei. Es gab aber keinen vSwitch. Die Lösung: In den Eigenschaften der Netzwerkkarte war tatsächlich noch die Checkbox beim Hyper-V-Switch gesetzt. Einmal deselektieren und dann konnte endlich der Switch an das Interface gebunden werden.

Importieren von VM? Fehlanzeige – manchmal!

Ich hätte vorgewarnt sein müssen, aber – frei nach dem Motto “Alles wird Gut” – wurden nun die VM auf der alten Plattform (Windows Server 2012 R2) exportiert, übertragen und importiert. Alles ohne Probleme – wunderbar!

Doch nichts währt ewig: Von 8 importierten VM lassen sich nur 4 Starten. Der Hyper-V-Worker wirft hier den Fehler 18560 und verweigert des Start.

Das Phänomen scheint die Gen2 VM zu betreffen, zumindest ist die einzige Gen1 VM ohne Probleme gestartet (Debian 8).
Nicht gestartet sind Server 2012R2 Gen2 VM. Zum Error 18560 kann man auch lesen, dass man die Energieeinstellungen anpassen soll; diese sind im UEFI als “Virtualization: High Performance” ausgewählt, auch andere Energieschemata haben nicht geholfen (davon abgesehen: Warum laufen dann ein Teil der VM, ein anderer nicht…?)

Screenshot der Ereignisanzeige für den Hyper-V-Worker

Ein bisschen Lösung

Nach weiteren Versuchen habe ich den Import an dieser Stelle abgebrochen (der Kunde möchte ja auch irgendwann wieder arbeiten), und habe einfach nur die .VHDX-Dateien kopiert und eine neue VM damit gebaut – zumindest das funktionierte tadellos.

Wenn Ihr nicht importieren könnt, denkt daran, dass beispielsweise die MAC-Adresse händisch angepasst werden muss, damit DHCP oder eventuelle Lizenzbindungen weiter funktionieren wie gewohnt.

Hyper-V 2019 – ist das wirklich RTM?

So richtig überrascht bin ich leider nicht mehr – und alleine das sollte Microsoft zu Denken geben. In Redmond bekommt man das Client-Betriebssystem angesichts immer kürzerer Releasezyklen nicht in den Griff, auch auf eigener Hardware. Und dann wird diese fatale Spirale auch auf den Server übertragen – was wird wohl das Resultat sein? Ich bin mit Server 2016 nie ganz warm geworden, irgendwie unfertig und nicht in dem Maße stabil wie man es von 2008 R2 und 2012 R2 gewohnt war.

Natürlich gab es die Hoffnung, dass 2019 so etwas wie ein R2 wird, aber das sieht für mich nicht so aus. Wir haben eine Software erhalten, die einen bisherigen Routineprozess von wenigen Stunden auf zwei Arbeitstage aufgebläht hat. Lasse ich das den Kunden zahlen, wird er – zu Recht – auf die früheren, problemlosen Migrationen verweisen. Dass Basisfunktionen wie das Einrichten eines virtuellen Switches nicht funktionieren ist nicht RTM-würdig.

Ich denke die Antwort auf die Frage: “Hyper-V 2019 – ist das wirklich RTM?” haben wir alle schon im Hinterkopf. Und: Warum kann man nicht einfach vorhandene Bugs sorgfältig ausmerzen, anstatt ständig neue einzubauen?

Schreibe einen Kommentar