[English]Ich ziehe mal ein Problem heraus, und skizziere es hier in einem Artikel, welches mir gerade in einer Facebook-Gruppe untergekommen ist. Ein Administrator lief in das Problem, dass der unter VMware vCenter 8.0 nach Installation des Update 2a nur noch eine leere Einstellungen-Seite für seine virtuellen Maschinen vorfand. Es gibt bisher keine Lösung, der Hersteller arbeitet aber daran.
Anzeige
Das Problem
Der betroffene Administrator staunte nicht schlecht, als sein VMware vCenter 8.0 nach Installation des Update 2a nur noch eine leere Einstellungen-Seite für seine virtuellen Maschinen zeigte. Er beschrieb es so:
Hallo zusammen, habe nach dem neuesten vCenter Update (8.0 Update 2a) das Problem, dass bei manchen VMs die Einstellungen komplett leer sind (siehe Screenshot). In den known issues und im Netz habe ich nichts entsprechendes gefunden. Auch aus dem vpxd.log werde ich nicht schlauer. Hat noch jemand einen Tipp?
Weitere Nutzer vermuteten ein Cache-Problem in dieser Umgebung. Aber daran liegt es nicht, und aktuell noch gibt keine Lösung.
VMware hat einen Support-Beitrag
Der betroffene Administrator hat dann selbst die Erklärung im VMware Support-Beitrag Edit settings window fails to load on Virtual Machines with virtual hardware version 9 or older on vCenter Server 8.0U2 (94979) gefunden. Das Problem tritt auf, wenn folgende Bedingungen vorliegen:
Anzeige
- vCenter Server Version ist 8.0 U2 – 22385739
- Virtual Machine Hardware Version 9 oder niedriger
- Virtual Machine ist im Powered on-Status
Beim Öffnen von "Einstellungen bearbeiten" werden die Registerkarten "Virtuelle Hardware" und "VM-Optionen" mit einem roten Ausrufezeichen angezeigt; der Rest des Fensters ist leer. Dann ist es nicht möglich, virtuelle Maschinen mit virtueller Hardware Version 9 oder älter über den vSphere-Client zu verwalten, während sie eingeschaltet sind. VMware ist sich dieses Problems bewusst und arbeitet daran, dieses Problem in einer zukünftigen Version zu beheben.
Anzeige
geht das Gemurkse nun auch bei vmware los … Ist das schon die Folge des Verkaufs? Ich wollte privat esxi 8 proxmox 8 vorziehen – da esxi über die Jahre "unzerstörbar" lief. vcenter hätte ich in der freien Lizenz ja nicht. Aber mit den neuen Aktionär*innen der 8er Version. Hmm.
Das hat nichts mit dem Verkauf zu tun, das kriegen die alleine hin. Die Version 7U3 hatte anfangs auch ganz eklatante Bugs drin, die wurde sogar zeitweise komplett zurückgezogen. Hatte ich vorher bei VMWare noch nicht erlebt. Bei uns sagen wir schon seit einer Weile, die sollen da nicht so viele Microsoft Entwickler einstellen bzw. abwerben.
Inzwischen warten wir mit Upgrades auf neue Haupt- und Minorversionen immer eine ganze Weile ab. Meistens geht's nach so drei Patchen mit den neuen Versionen, dann sind die übelsten Bugs zumeist behoben.
Die "älteren" Versionen (7U3 bzw. 8U1) sind ja auch noch im Support, so dass man da nichts verliert, wenn man wartet.
VMware hatte noch nie den besten Ruf, wenn es um Updatequalität geht. Wie so ein Fehler übersehen werden kann, erschließt sich mir jedoch nicht. Was aber noch viel schlimmer ist, dass es seit mindestens 16.10. bekannt ist und seitdem weder einen Patch, noch einen sauberen Workaround gibt.
Scheinbar ist ja
"ESXi 5.5 and later (VM version 10)" Vorraussetzung
Warum sollte dann also eine Qualitätskontrolle mit älteren Versionen gemacht werden.
Solange die alten HW-Versionen von VMWare für 8U2 nicht als "deprecated" oder "unsupported" bezeichnet werden (was sie soweit mir bekannt ist nicht sind) bzw. VMs und OVAs mit solchen Versionen weiterhin von ESXi und Vcenter ohne Warnungen akzeptiert werden ist das eine supportete Kombination. Also sollte die QS das auch entsprechend testen.
Stimmt das vCenter sollte diese ablehnen
Der Verkauf an Broadcom ist noch nicht durch aber ja es richt streng.
Danke für den Artikel. Leider führt VMware das Problem nicht in den Release Notes unter den known issues auf, weshalb ich es auch nicht sofort gefunden habe.
Das Ganze sollte ja doch einen nicht unerheblichen Kreis betreffen.
Musste gerade eben mal nachsehen, Hardware Version 9 ist ja schon ewig alt, gehört zu ESXi 5.1, da muss man schon ordentlich abgehangene Schinken noch mit sich rumschleppen, dass man das noch hat. Hier läuft 8.0 U2 problemlos.
Soweit sehe ich die Sache nicht als kritisch.. VM-Version 9 ist nun doch schon etwas älter (ESX 5.1).. Einfach die betroffenen VM's kurz runterfahren und die VM-Version aktualisiert. Bei uns soweit keine Probleme bei dem Prozedere..
Ein Backup sollte man natürlich trotzdem immer zur Hand haben ;)
Hardware Version 9?
Also Entschuldigung, aber aktuell ist die 19.
Bisl mit der Zeit gehen, dann läufts auch nicht aus dem Ruder
Wollt auch "Also Entschuldigung" sagen :-) Aktuell wär hier laut VMware (!) :
21 für ESXi 8.0 U2 (8.0.2), Workstation Pro + Player 17.5
19 ist @ ESXi 7.0 U2 (7.0.2), Workstation Pro + Player 16.2.x
Es empfiehlt sich (nach meiner Erfahrung) die virtualHW.version zumindest alle paar Monate nachzuziehen, bei VMplayer = "XY" im vmx-File im Storage. Die sind zu pflegen ! ZB gegen Symptome wie:
– Virtual machine fails to power on.
– Some VM operations are greyed out/unavailable.
– Unexpected behavior in a guest OS.
– False Guest OS Storage-reporting.
-> Eine meiner Lieblings-Auditprüfungen bei ESX :-) :-)
OS muss das mitmachen, will auch getestet werden, OS auf shutdown. Sonst meckerte der Host schon mal mit Warnung "Hardware zu alt" beim Start. HA-Environments sind wohl gesondert zu betrachten.
Wie macht Ihr das? Manuell wie ich? oder gibts da nen eleganteren Weg den nur "VMware Certified Practitioner Level Gold & Coffee" – Admins kennen?
Und wie handhabst du das mit fertigen Appliances, wie z.Bsp. dem Vcenter selbst? Der wird wie weiter unten erwähnt von VMWare selber mit der Version 10 ausgeliefert. Von deren Installer wohlgemerkt.
Wie oben angedeutet + gefragt per Teil-Manuell. Wenn zB lt. Aufzählung VMware von oben Nr 1:
– neue (Sicherheits-)Features durch VM-Tools dies erfordern
– Vmotion o. mehr CPU-cores kommen könnten: >=Version 15
– Im Pool/HA empfehle ich gemeinsamen Nenner für ALLE.
Die im Link zitierte "Warning: Upgrading..HW.. not recommended.. unless features.. are needed" sollte sich
bei Version 21 vs. (hier im Blog) 9 eher erübrigen, ESX 5.5 mit HW 10 ist EOL seit 3J+, schon 6.5 ist EOS seit 2022.
D.h.: Auch für viele Appliances gilt mE Einzelfallprüfung, Abwägen Sicherheitskriterien, Bedürfnisse für Failover, Notfallmigration oder nur "Update und Test".
Diese Abwägung ist Aufgabe eines guten Admins. Nüsch nur "DVD reinstopfen und gut" :-p :-p
DASS ich das gern "besser" hätte ist wohl klar. DASS VMware hier echt Schnecke ist gilt nicht nur hier, zB auch für Tools, siehe Borncity hier – daher fragte ich wie ihr das macht, Ich folgere aus diesem Thread: Einige machen es gar nicht ;-)
"D.h.: Auch für viele Appliances gilt mE Einzelfallprüfung, Abwägen Sicherheitskriterien, Bedürfnisse für Failover, Notfallmigration oder nur "Update und Test".
Diese Abwägung ist Aufgabe eines guten Admins. Nüsch nur "DVD reinstopfen und gut" :-p :-p"
Sorry wenn ich da noch mal einhake, aber ich rede von fertigen Appliances, die vom Hersteller bereit gestellt werden und i.d.R. als OVA geliefert werden. Ggfls. auch ohne Zugangsdaten zum drunter liegenden OS. In der Dokumentation steht dann sowas wie "Anpassungen an den Einstellungen, die nicht explizit in der Doku stehen, werden nicht supported". Teilweise darf und ggfls. kann man wg. fehlenden Root-Credentials nicht mal Linux-Patche einspielen, das passiert dann erst beim Update auf die nächste Version der Appliance.
Da ist nichts mit "Einschätzen, umstellen und testen", dann verlierst du den Herstellersupport. Und wenn dass dann ein essentielles System, wie z.Bsp. ein Lizenzserver ist, werde ich wohl kaum riskieren, keinen Support zu haben, wenn da was schief läuft.
VMware hatte schon zu tiefsten vSphere 5.x Zeiten das Update der Tools von den Updates der ESXi-Hosts getrennt. Die Tools kann man mindestens seit dem Zeitpunkt via .vib direkt auf dem Host oder über eine Baseline via vCenter auf den einzelnen Hosts updaten, ohne das ein Neustart der Hosts oder gar ein schalten dieser in den Maintenance-Mode erforderlich ist. In den einzelnen ESXi-Releases und Updates, sind nur noch die zu dem Zeitpunkt aktuellen Tools enthalten. Sollten dazwischen neuere rauskommen, hat man sich, als guter Admin, also selbst zu kümmern und diese einzuspielen.
Abgesehen davon: Was für tolle Features vermisst man denn, dass man bestehende VM zwingend auf die aktuellste HWV hochziehen muss?
docs.vmware.com/en/VMware-vSphere/8.0/vsphere-vm-administration/GUID-789C3913-1053-4850-A0F0-E29C3D32B6DA.html
Das liest sich aufregend unaufregend. UEFI? Seit ESXi 5.0/HWV 8. Secure Boot? Seit ESXi 6.5/HVW 13.
Was haben denn jetzt die VMware Tools bitte damit zu tun? Hier geht es doch um die HW-Version der VM. Zumal gerade bei fertigen Appliances meist ein Linux drunter liegt, dass die Tools selber verwaltet. Steht dann auch entsprechend im Vcenter als "Verwaltet durch Gast". Da kannst du dann auch vom Vcenter oder ESXi aus auch kein Update fahren, dass kommt dann höchstens bei einem Update der Appliance selber mit. Aber auch da bist du auf den Hersteller angewiesen.
Die Antwort bezog sich auf die von "Norddeutsch", der im letzten Teil seines Kommentares die VMware Tools ins Spiel brachte.
Vom vCenter und den vCLS-Maschinen lass mal die Finger. Das ist erstens nicht supportet und zweitens läuft das tatsächlich nicht. Hab ich mal beim vCenter probiert, das fährt dann nicht mehr hoch.
Ganz einfach: die HW-Version wird bei selbst aufgesetzten VMs auf die aktuellste supportete Version gestellt und bleibt für den Rest des VM-Lebens so. Die einzige Ausnahme sind Spezialanwendungen, die ein neues Feature benötigen (zB DB-Server und die NUMA-Änderung von einer der letzten Versionen).
Bei fertigen Appliances wird gar nichts geändert.
Gibt genug VMware-Dokumente, die es genau so empfehlen und ich hatte auch schon ein paar Mal Probleme nach einem HW-Update – u.a. bei diversen, obskuren Lizenzschutznervsachen. Unterm Strich hilft es mir auch nicht, wenn es bei 99,9% der HW-Upgrades keine Probleme gibt aber die 0,1% sind genau die hochkritischen Systeme, bei denen Du alles nur keinen Ausfall brauchst.
Das sich die VMware bei der HW-Upgrade-Politik selbst widerspricht ist mir übrigens bekannt.
Die VMware Tools sind immer am aktuellen Stand. Die werden spätestens im Rahmen des monatlichen Patchdays verteilt. Leider nicht (mehr) automatisiert seitdem die Abhängigkeit von .Net zu gross geworden ist.
Aktuell ist die 21. ;-)
Naja, Hardware-Version 9 mit VCenter 8 ist schon unpassend, kommt aber leider vor, wenn man Vorlagen von Herstellern benutzt und dann nicht anpasst. Tatsächlich die letzte deployte VM bei mir hier auch.
Anmerkung am Rande über das Wundern über Hardware Version 9 und wie niedrig das doch sei: vCenter 6.7, 7 wie auch vCenter 8 werden mit Compatibility "ESXi 5.5 and later (VM version 10)" deployed.
Auch fertige Appliances von anderen Herstellern werden mit teils ewig alten Versionen ausgeliefert. Habe auch noch so ein paar Version 10 Kandidaten bei uns. Und die fasst man i.d.R nun mal nicht an, da nicht einschätzbar ist, wie sich das auf die VM auswirkt, speziell wenn das OS eine "Blackbox" ist, also der Hersteller hier keine Zugangsdaten für den Root rausgibt. Wobei man dazu sagen muss, bei fertigen Appliances ändert man i.d.R auch die Hardwarekonfiguration nach dem Deploy nicht mehr.