VMware-Forum

Hallo,
eigentlich wollte ich unsere Dell Server auf 7.0 updaten wie ich es immer gemacht habe :
host in Maintenance-Mode schicken, von dem ISO bootem, Update auswählen, richtigen Speicher auswählen und fertig.
Leider funktioniert das auf einmal nicht mehr. Es kommt eine Fehlermeldung und das ich eine andere Art des Updates benutzen sollte (esxcli oder vLCM)

Also komme ich nicht darum herum mich mit dem "Updatemanager" bzw. LifecycleManager zu beschäftigen.

Angesehen, sieht nicht schwierig aus, aber ein paar Fragen und Unsicherheiten bleiben.
Wir haben einige Cluster im Betrieb. Ist es ok Cluster beim update anzugeben?
Eigentlich würde ich das lieber erstmal hostweise probieren. Oder ist das egal?

Egal ob update über host- oder Cluster, HA und DRS bleiben dabei an?
Was passiert wenn er eine VM wegen z. B. eines CD Laufwerks nicht verschieben kann, wird der ganze update Prozess dann abgebrochen?

Irgendwie trauer ich doch der alten Vorgehensweise etwas hinterher, vor allem seit ich das ISO Image im IDRAC einbinden konnte.

Grüße
Jens

Nur kurz..... es waere ja schoen gewesen wenn du die Meldung gepostet haettest. Da ich hunderte von Server und davon 99.9% Dell Hosts aktualisiert habe kann ich mir eigentlich nur das "Standardproblem" vorstellen. Dieses betrifft aber alle Vendor ESXi und auch die VMware Vanilla Hosts.

Bestimmte Treiber Module sind entfallen und haben keinen direkten Nachfolger so das nicht loesbare Abhaengigkeiten(Dependencies) entstehen. Das trifft den 7.0 besonders da hier die alten VMKlinux basierten Module nicht mehr verwendet werden koennen und alle Anbieter nur noch die "NG" Variante liefern duerfen.
Zu dem kommt dann ein Dell spezifischen Verhalten welches die OpenManage(OMSA), RACADM(iDRAC Tools) angeht welche auch sehr gerne und auch spaeter innerhalb der 7.x auffallen. Die Loesung ist aber in beiden Faellen die gleiche und lautet das die VIBs ueber die Treibernamen identifiziert werden muessen und dann entfernt werden.

Weitere Probleme bei einem Upgrade/Update sind
1. Defekte ESXi Bootbanks
2. Error -28 No space left on device
3. Zu kleine Bootdatentraeger(Dell SD Karten).

All die Probleme sind die gleichen wenn es um die Methode ISO, esxcli mittels OfflineBundle(*.zip)/direkt Download oder vLCM geht. Bei der esxcli siehst du die Meldung aber sehr gut und kannst das Problem oftmals sofort beheben und es sofort nochmal versuchen. Bei ISO und vLCM rennst du in den Fehler und der Versuch wird abgebrochen und der ESXi neu gestartet damit du dann auf der Kommandozeile das Problem behebst.

Zum Rest
- vLCM unterscheidet Host Upgrade und Baselines?(normales Patchen)
- vLCM hat eine konfigurierbare Option was CDROMs angeht
- Ueber den Cluster zu patchen ist nur praktikabel wenn du DRS lizenziert und im Einsatz hast weil er sonst wartet das der Host in den Wartungsmode geht. Das muesstest du ja sonst manuell machen und beim Cluster sucht die Automatik sich wahllos einen der Hosts aus
- Ich mache zumind. den ersten Host per vLCM/esxcli um zu gucken was es an Problemen gibt


Ansonsten... die Methode die ISO zu booten steht auch unter 7.x nach wievor zur Verfuegung und ist nicht generell entfernt worden.

Gruss
Joerg

Dank für die Infos.
von der Fehlermeldung habe ich nur einen snapshot gemacht:



Dell Support empfiehlt vLCM zu nehmen. Die kennen das Problem wohl, konnten aber noch nicht herausfinden wer der Verursacher ist.?
Das wird wahrscheinlich dann auch mit vLCM nicht klappen und werde dann letztendlich über esxcli gehen, denn so wie du das schilderst gehe ich auch davon aus das es die VIBs sind.
Alle anderen möglichen Probleme scheiden aus. Ich benutze immer noch zwei gespiegelte HDDs/SSDs für die VMware Installation. Da ist auch noch jede Menge freier Platz.

Ich werde die hosts einzeln updaten, obwohl wir DRS lizensiert haben.
Scheint mir für das erste Mal der bessere Weg zu sein.

Beim nutzen von esxcli liegt das bundle ( bei offline installation) ja auf einem shared storage. Wenn ich beim ersten host die störenden VIBs herausnehme/ausklammere , wird das dann in dem bundle abgespeichert, so das ich das beim nächsten host nicht wiederholen muss?


Grüße
Jens

hab da jetzt auch was von VMware gefunden:

https://kb.vmware.com/s/article/85859

Grüße
Jens

Danke fuer den nachgereichten Screenshot. Den hab ich in der Tat noch nicht gesehen weil sonst stehen da die Treibermodule drauf an denen er sich stoert oder aber zumind. ein Fehler Code/Meldung. Bei dir steht steht ja nichts sinnvolles drauf.


Ob das Offline Bundle auf Local/Shared Storage liegt spielt keine Rolle wobei nachtuerlich das Shared Storage seinen Vorteil hat wenn man mehrere Hosts.

entfernt die VIBs aus der sekundaeren Bootbank und nicht dem Bundle.


In einer zweiten Shell kann man im esxupdate.log mitlesen bzw. es gibt passendes Feedback von esxcli direkt auf der Konsole.

Gruss
Joerg