[English]Kleiner Hinweis für Benutzer von HPE-Servern, die VMware ESXi 6.5 Update 3 mit einem Custom-Image einsetzen. Ich bin gerade über einen Problembericht gestoßen, dass es mit dem Custom-Image Probleme gibt.
Hintergrund ESXi 6.5 Update 3 HPE Custom
Der VMware ESXi ist ja ein Bare-Metal-Hypervisor, also ein Minimalbetriebssystem, welches sich direkt auf Ihrem physischen Server installieren lässt. Anschließend können dort virtuelle Maschinen auf dem Server aufgesetzt werden. VMware bietet hier einigen Informationen zum ESXi-Hypervisor an.
Für HP-Server (ProLiant) werden angepasste VMware ESXi-ISO-Dateien zur Installation angeboten. Diese enthalten alle erforderlichen Treiber und die Managementsoftware zur Ausführung von ESXi auf HPE Servern. Zudem soll diese angepasste Installation, laut dieser HP-Ankündigung, nahtlos mit Intelligent Provisioning zusammenarbeiten. HP schreibt:
Für eine erfolgreiche Installation ist bei bestimmten ProLiant Servern das kundenspezifische Image von HPE erforderlich. Die Treiber für die neuen Netzwerk- und Storage Controller in den Servern sind im kundenspezifischen Image von HPE integriert und sind nicht Teil des allgemeinen ESXi-Image, das von VMware vertrieben wird. Für den Einsatz von ESXi müssen die Treiber für diese Controller integriert sein, da Sie die Controller nicht während der Installation hinzufügen können.
Eigentlich eine feine Sache, die verschiedenen Downloads und weitere Details stehen auf dieser HP-Seite zur Verfügung. Zudem bietet VMware auf dieser Webseite Informationen und Images an.
Warnung vor Problemen
Es ist aktuell nur eine Einzelstimme – ich habe bei einer kurzen Suche keine weiteren Treffer gefunden. Auf administrator.de findet sich dieser Beitrag, auf dem ein Nutzer seine Erfahrungen beschreibt.
ich hatte die Tage eine unschöne Begegnung mit dem ESXI 6.5 Update 3 HPE Custom.
Bei einem Clean Install auf zwei unterschiedlich konfigurierten ML350 Gen10 reagiert ca. 2 Minuten nach dem Hochfahren das Management Interface nicht mehr. Weder über das WebUI, noch über die Konsole via F2 (auch nicht über Alt F1). Man kann einzig über F12 den Server runterfahren oder neustarten.
Firmware ist jeweils „aktuell“ auf Level der HP SPP 2019.03 (2019.06 wurde noch nicht released). Auf 6.5 U2 HPE Custom laufen die Server normal.
Noch jemand, der mit dieser Konstellation arbeitet und ähnliche Erfahrungen gemacht hat?
Ähnliche Artikel:
VMware ESXi: Absturz des Hosts beim Herunterfahren einer VM mit PCI-Passthrough
Hmmm, vor allem viele Treiber Updates, siehe https://www.vladan.fr/vsphere-6-5-update-3-released/ jetzt wäre natürlich Frage inwieweit sich das mit der HPE-Anpassung beißt. Andererseits bin ich zu 6.0er Zeiten Auch schon mal über sowas, allerdings mit DELL-custom, gestolpert, ob die beide ja eigentlich quasi eine Bude sind/waren. Damals lag es auch an einer kleinen Schweinerei beim HBA-Treiber.
Ich habe ein ähnliches Problem mit 2 HPE DL360 G9. Kurze Zeit nach dem Hochfahren reagiert der Host nicht mehr. Das Beenden des Wartungsmodus ist nicht möglich, die Anzeige der Hardware-Sensordaten ebenfalls nicht. Falls der Wartungsmodus sofort nach dem Hochfahren beendet wird und VMs gestartet werden, hängt der Startvorgang der VMs bei ca. 20%. Nach einer Weile (von 5 – 20 Minuten habe ich unterschiedliche Szenarien erlebt) reagiert der Host wieder und kann von da an normal genutzt werden. Firmware, Treiber und Management Bundles sind auf dem aktuellen Stand (SPP2019.03.1). Ein Neustart des Servers ist während dieser Zeit nicht möglich, weder über VCenter, noch über die Konsole am Server. Es bleibt nur ein Stromreset.
Hast du ebenfalls eine Clean Install gemacht, oder nur VMware-Updates?
Zunächst habe ich beide Server mit dem HPE-ISO 6.5 U2 über den VMware Update-Manager von 5.5 U3 auf 6.5 U2 aktualisiert. Als nach dem Einspielen von 6.5 U3 über den Update-Manager die Probleme auftraten, habe ich einen Server mit dem HPE-ISO 6.5 U2 neu installiert. Nach dem Einspielen von 6.5 U3 über den Update-Manager ist das Problem wieder aufgetreten.
Hallo,
ich denke auch, dass es mit den vielen Treiberaktualisierungen zu tun hat, bzw. dass das 6.5 U3 HPE Custom einfach der Server-Firmware voraus ist und sich die Probleme entweder mit dem manuellen Akutalisieren der einzelnen Firmwarekomponenten, oder mit dem nächsten SPP lösen werden.
Puh, das ist hässlich. Dann hat das nämlich mit der HPE Custom gar nichts zu tun. Die hast du unter diesen Umständen ja gar nicht drauf.
Wartet der Server bei jedem Neustart so lange, oder ist das nur einmalig?
Dann warte ich mal noch mit dem Update auf unseren DL360 Gen9. :-D
Ich hab auf der anderen Seite noch einen Fujitsu TX150 S8 mit ESXi 6.5 U2 Fujitsu Custom (unsupported (Support nur bis ESXi 6.0)) via Clean Install betankt und dann das VIB-Update auf U3 gemacht.
Der Fujitsu hat zumindest keine Probleme mit U3 in Richtung Management, deshalb denke ich, dass sich das Problem rein auf HPE bezieht (wobei mein Test mit Fujitsu hinkt).
Nachtrag: Ich habe soeben mal direkt auf der Download-Seite des ML350 Gen10 nachgeschaut, dort ist das 6.5 U3 HPE Custom gar nicht gelistet.
Heißt für mich: Entweder hat HPE den Custom U3 Build selber noch gar nicht offiziell freigegeben, oder wieder zurückgezogen.
@chgorges: Bezüglich Verfügbarkeit/Rückziehung des Images duchaus valider Punkt, aber wie so oft, dann mal wieder ein schönes Beispiel von HOW NOT TO DO bezüglich Kundenkommunikation 😜
Wir haben auf unseren HPEs, schon vor einiger Zeit, ESXi durch Proxmox ersetzt. War alles einfacher als gedacht und funktioniert hervorragend. Auch das Update auf die 6.0 war problemlos. Super Sache, hätten wir schon viel früher machen sollen.
Grüße aus dem Erzgebirge
Das ist ja ne super Sache. Ich setze mich sofort hin und löse unsere Cluster mit Proxmox ab. Nicht.
https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE
Auch wenn der Artikel viele unterschiedliche Szenarien abfrühstückt, so ist doch allein am Umfang dieses einen Artikels mit gefühlt über 9000 Querverweisen schon zu erkennen, dass das nicht mal eben so in einer Nachschicht/an einem Wochenende erledigt ist. Ferner ist auch immer, abgesehen vom Monetären die Frage des Warum, die kaum bis nie jemand wirklich beantworten kann und Open Source ist da genauso „valide“ Antwort wie „fahr doch mit der Bahn“ statt zu fliegen.
Ja, was ich damit sagen wollte: Es geht hier um explizite Probleme mit HPE Servern unter ESXi 6.5. Wenn es dazu etwas beizutragen gibt, sehr gern.
Dass es neben ESXi auch noch Hyper-V, Xen, Proxmox, Oracle VM Server usw. gibt, tut hier absolut nichts zur Sache. Ich freue mich für dich, dass das bei euch super läuft. Interessiert aber in diesem Zusammenhang hier niemanden.
Das gleiche Problem tritt anscheinend auch auf IBM/Lenovo x3650M5 Server mit 6.5 U3 Lenovo Custom Image auf. Nach dem Booten kann der Wartungsmodus nicht beendet werden und ein Login per SSH, DCUI oder Web Console ist nicht möglich…
Treiber und Firmware ist alles VMware HCL konform….
Nach x Minuten alles wieder in Ordnung.
Ist jemand auch auf „Admission Failures“ im vmkernel.log gestoßen?
2019-08-05T10:10:00.629Z cpu18:69617)MemSched: 14635: Admission failure in path: hostd-probe/stats/sh/sh.69617/uw.69617
2019-08-05T10:10:00.629Z cpu18:69617)MemSched: 14642: uw.69617 (25122) extraMin/extraFromParent: 128/128, hostd-probe (732) childEmin/eMinLimit: 5366/5376
Hallo, das gleiche Problem hatte ich heute auch bei BL460Gen9 Servern. Aktuelle Firmware und ESXi 6.5 U3.
Bei Mir ist aber aufgefallen, wenn man HA im Cluster deaktiviert gibt es keine Probleme.
Mit aktiviertem HA war teilweise auch keine Migration einer VM mehr zwichen den Hosts mit U3 möglich.
Das ganze war mehrmals reproduzierbar!
Please Check https://kb.vmware.com/s/article/74966 for a Workaround!
[root@esx:~] localcli system wbem provider list
Name Enabled Loaded
————————————-
sfcb_base true true
vmw_base true true
vmw_hdr true true
vmw_hhrcwrapper false false <<<< Dissable this
vmw_hpe-smx-provider true true
vmw_iodmProvider true true
vmw_kmodule true true
vmw_omc true true
vmw_pci true true
vmw_vi true true
[root@esx:~]
Gibt zum englischsprachigen Beitrag den Kommentar, dass man CIMSVC deaktivieren solle. Dann ginge es.
und dann hat man kein Monitoring mehr. schlechte Idee.
Ich habe sieben Server mit ESX 6.5 U2 (Einzel-Hosts, kein Cluster, da privat Nutzung der Server) auf das Update 3 direkt online upgedatet (per https://esxi-patches.v-front.de/ESXi-6.5.0.html).
Natürlich bei dem letzten und wichtigsten Server ist das ESX-System scheinbar eingefroren und reagierte nicht mehr nach dem vollständigen Booten, alle anderen sechs Server hatten das Probleme nicht.
Erstaunlich, da zwei Server softwaretechnisch und hardwaretechnisch absolut identisch sind (HP DL385 G7 | 2x Opteron 6174 12-Core).
Nach einigen Panik-Attaken habe ich einfach lange gewartet, und dann lief nach ~30 Minuten der Server wieder. Danach den letzten Patchstand nachgezogen, und seit dem läuft der wieder. Sonst hätte ich wohl ein Rollback machen müssen.
Irgendetwas hat der Server nach dem ersten Reboot ziemlich lange gemacht, es gab auch eine Meldung im Log, dass einige SW-Pakte entfernt wurden (?) – genauer weiß ich es jetzt aber nicht.
Ich überlege trotzdem, nun ein Rollback zumachen, da mir erst viel zu spät aufgefallen ist, dass der PRTG Hardware-Sensor nicht mehr funktioniert.
Außerdem werden die Power-Werte der Netzteile nicht mehr richtig ausgelesen, und zeigen nur noch 1 Watt an.
Auf einem noch älteren HP DL180 G6 funktioniert allerdings das HW-Monitoring auch mit Update 3 weiterhin.
Leider ist das bequeme Rollback per Boot-Menü jetzt nicht mehr möglich, da durch die Patchinstallation nach dem Update 3 die letzte Version schon zu neu ist. :(
Hier geht’s weiter, VMware hat bestätigt:
https://kb.vmware.com/s/article/74966