Vorsicht beim Update auf ESXi 6.5 Update 3 HPE Custom

Windows Update[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

Dieser Beitrag wurde unter Virtualisierung abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

21 Antworten zu Vorsicht beim Update auf ESXi 6.5 Update 3 HPE Custom

  1. Henry Barson sagt:

    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.

  2. 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.

    • riedenthied sagt:

      Hast du ebenfalls eine Clean Install gemacht, oder nur VMware-Updates?

      • Torsten Weber sagt:

        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.

        • chgorges sagt:

          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.

        • riedenthied sagt:

          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

          • chgorges sagt:

            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).

          • chgorges sagt:

            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.

          • Henry Barson sagt:

            @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 😜

  3. Sven Fischer sagt:

    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

    • riedenthied sagt:

      Das ist ja ne super Sache. Ich setze mich sofort hin und löse unsere Cluster mit Proxmox ab. Nicht.

        • Henry Barson sagt:

          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.

        • riedenthied sagt:

          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.

  4. Marcel sagt:

    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

  5. CJu sagt:

    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!

  6. Boris sagt:

    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:~]

  7. Günter Born sagt:

    Gibt zum englischsprachigen Beitrag den Kommentar, dass man CIMSVC deaktivieren solle. Dann ginge es.

  8. Tim sagt:

    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. :(

  9. Christoph sagt:

    Hier geht’s weiter, VMware hat bestätigt:
    https://kb.vmware.com/s/article/74966

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert