Embedded ESXi Update Manager Problem

[roeschu]

Hallo

Habe ein paar HP Blades über die HP Custom Images via den Vmware Update Manager von 5.5 auf 6.0 upgedatet. Hat alles geklappt.

Nun wollte ich dasselbe mit Fujitsu Blades machen. Die Fujitsus haben Embedded ESX 5.5 (die HP Blades haben ESX auf der Festplatte installiert). Beim Update Prozess kommt bei den Fujitsus eine Fehlermeldung von wegen "could not create filesystem bla bla bla" o.ä (hab vergessen screenshot zu machen).

Ist ein 5.5 -> 6.0 Update für EmbeddedESX nicht möglich via Update Manager? Muss ich wirklich den ganzen Schmuh neu aufsetzen?

Grüsse

[JustMe]

Screenshot waere schoen, wie immer

Ich habe gerade nix zum Ausprobieren da, aber kannst Du mal schauen, wie die Partitionierung des UFM aussieht?

Beispielhaft:

Code: Alles auswählen

~ # [color=blue][b]fdisk -lu[/b][/color]

***
*** The fdisk command is deprecated: fdisk does not handle GPT partitions.  Please use partedUtil
***


Disk /dev/disks/mpx.vmhba32:C0:T0:L0: 4007 MB, 4007657472 bytes
64 heads, 32 sectors/track, 3822 cylinders, total 7827456 sectors
Units = sectors of 1 * 512 = 512 bytes

                           Device Boot      Start         End      Blocks  Id System
/dev/disks/mpx.vmhba32:C0:T0:L0p1            8192     1843199      917504   5 Extended
/dev/disks/mpx.vmhba32:C0:T0:L0p2         1843200     7086079     2621440  fc VMKcore
/dev/disks/mpx.vmhba32:C0:T0:L0p4   *          32        8191        4080  ef EFI (FAT-12/16/32)
/dev/disks/mpx.vmhba32:C0:T0:L0p5            8224      520191      255984   6 FAT16
/dev/disks/mpx.vmhba32:C0:T0:L0p6          520224     1032191      255984   6 FAT16
/dev/disks/mpx.vmhba32:C0:T0:L0p7         1032224     1257471      112624  fc VMKcore
/dev/disks/mpx.vmhba32:C0:T0:L0p8         1257504     1843199      292848   6 FAT16

Partition table entries are not in disk order


oder ist es vielleicht in GPT eingerichtet?

Eventuell verhaspelt sich der Upgrade-Prozess mit den vorhandenen Partitions; dann bliebe eventuell, die aktuelle 5.5er Konfiguration zu speichern, genau diese 5.5er Version neu auf das UFM zu klatschen, und die Konfig zurueckzuspielen. Eventuell gibt's dann eine "upgrade-faehige" Partitionierung...

Ich konnte es eben nur mit einer 4GB Platte an einer VM ausprobieren; die wird bei einer 5.5u2 Installation nach GPT mit nur noch 5 Partitions (im Protective-MBR) umgewandelt...

[roeschu]

~ # fdisk -lu

***
*** The fdisk command is deprecated: fdisk does not handle GPT partitions. Please use partedUtil
***


Disk /dev/disks/mpx.vmhba32:C0:T0:L0: 4007 MB, 4007657472 bytes
64 heads, 32 sectors/track, 3822 cylinders, total 7827456 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/disks/mpx.vmhba32:C0:T0:L0p1 8192 1843199 917504 5 Extended
/dev/disks/mpx.vmhba32:C0:T0:L0p2 1843200 7086079 2621440 fc VMKcore
/dev/disks/mpx.vmhba32:C0:T0:L0p4 * 32 8191 4080 ef EFI (FAT-12/16/32)
/dev/disks/mpx.vmhba32:C0:T0:L0p5 8224 520191 255984 6 FAT16
/dev/disks/mpx.vmhba32:C0:T0:L0p6 520224 1032191 255984 6 FAT16
/dev/disks/mpx.vmhba32:C0:T0:L0p7 1032224 1257471 112624 fc VMKcore
/dev/disks/mpx.vmhba32:C0:T0:L0p8 1257504 1843199 292848 6 FAT16

Partition table entries are not in disk order

Auch Upgrade über ISO (also nicht durch Update Manager) hat nicht funktioniert. Nur komplette Neuinstallation hat geklappt.

[JustMe]

Aaaaalso, dann schauen wir mal.

Zuerst fiel mir auf, dass bei Dir wie in meinem Beispiel auf dem UFM ZWEI (i.W.: Z-W-E-I) VMKcore Partitions (type 0xfc) zu finden sind.
Dann meldet der Update-Prozess doch auch tatsaechlich, dass er Partition :2 nicht bearbeiten koenne.
Offenbar stolpert der also genau darueber.
Warum da jemand bei FTS auf die Idee kam, im Partition-Layout tatsaechlich 2 von den Dingern anzulegen, tja,

Auf jeden Fall:
Wenn man die P2 (die ja physisch am Ende des Mediums liegt und nicht wie die P7 mittendrin) loescht, laeuft danach der Upgrade-Vorgang ganz normal & schmerzfrei durch.
Nebenwirkungen:
- Auch wenn VORHER die P2 die aktive VMKcore-Partition ist, erkennt das ESXi 6.0 die P7, und aktiviert die nach dem Upgrade.
- Die P7 ist viel kleiner als die P2, kann also weniger Daten im Falle eines Falles aufnehmen.

Wer will, kann nach dem Upgrade ja wieder die P2 anlegen (einfach mit fdisk; auf dem UFM wird nicht nach GPT konvertiert), und per "esxcli system coredump partition set..." einstellen.

Ansonsten:
Generell waere ich mit einem Upgrade per Update-Manager vorsichtig; insbesondere wenn es nach 6.0u1 gehen soll, und in den Blades Emulex-Komponenten zu finden sein sollten. Eigentlich gilt das generell tatsaechlich fuer andere HW-Frickler auch, denn i.A. wird davon ausgegangen, dass neueste OS-Versionen auch auf neuesten Hardware-Versionen (BIOS, Firmware, ...) laufen. Und genau DIES prueft der vSphere-UM NICHT ab.

Viel Glueck!

[roeschu]

Besten Dank für deine Erläuterungen.

..., denn i.A. wird davon ausgegangen, dass neueste OS-Versionen auch auf neuesten Hardware-Versionen (BIOS, Firmware, ...) laufen. Und genau DIES prueft der vSphere-UM NICHT ab.

Verstehe ich nicht. Bedeutet dies im Umkehrschluss das wenn ich ein Fujitsu Blade neu (normal) mit ESX 6 aufsetze der Vmware Installationsprozess prüft ob die neuste Fujitsu Firmware (BIOS etc.) auf den Blades läuft?

Also ich lass es bei den Fujitsus blieben und mach eine normale Neuinstallation..sind nicht so wahnsinnig viele Blades, kann den Mehraufwand noch grad so verkraften. Zudem muss ich tatsächlich auch grad Bios/Firmware Updates machen auf den Fujitsu blades..

grüsse

[JustMe]

...Umkehrschluss das [...] der Vmware Installationsprozess prüft...

So schoen waere die Welt, wenn zweimal "falsch" ein "richtig" ergaebe.

Nein. Der Installationsprozess ist genauso "dumm" wie der Upgrade-Prozess. Die Software-Nullen und -Einsen werden einfach auf die Hardware gekippt, und schon ab da ist dann der Bediener/Administrator dafuer verantwortlich, dass das auch zueinander passt.

[roeschu]

Nein. Der Installationsprozess ist genauso "dumm" wie der Upgrade-Prozess. Die Software-Nullen und -Einsen werden einfach auf die Hardware gekippt, und schon ab da ist dann der Bediener/Administrator dafuer verantwortlich, dass das auch zueinander passt.

Dann ist aber deine "Vorsichtswarnung" betreffend Major Updates via Update Manager eigentlich obsolet....es prüft so oder so nicht ob jetzt beim manuellen Installationsprozess oder via VUM. Man muss es so oder so separat/"manuell" beachten

[JustMe]

Und genau deshalb habe ich gewarnt.

Weil naemlich sonst keiner drauf aufpasst.

Aber ich will hier definiitiv niemanden zu seinem Glueck zwingen

[Dayworker]

Solchen Murks hatten wir hier im Forum auch schon mit Intel-Nics. Deren Treiber wollte partout nicht starten, weil die FW zu niedrig war.
"Schön" das Intel sowas nicht als einzigster verk"§#t.