VMware-Forum

Hallo,

mein Versuch das Update zu installieren endet mit einer Fehlermeldung (siehe unten)
Auf einem Testsystem hat es vorab geklappt. Die Pakete sind also ok.
Auf dem betroffenen System konnte ich das Update einspielen nachdem ich den Host vorher einmal neu gestartet habe.
Kennt jemand diesen Effekt?

Gruss


http://communities.vmware.com/message/2024874
habe ich gefunden


esxcli software vib update --depot=/vmfs/volumes/vmware_files/esx50/update-from-esxi5.0-5.0_update02.zip



Image-Profil '(Updated) ESXi-5.0.0-20120302001-standard' konnte nicht bereitgestellt
werden: ('', 'The transaction is not supported: VIB
VMware_bootbank_misc-drivers_5.0.0-2.26.914586 cannot be live installed. VIB
VMware_bootbank_scsi-lpfc820_8.2.2.1-18vmw.500.2.26.914586 cannot be live installed.
VIB VMware_bootbank_esx-base_5.0.0-2.26.914586 cannot be live installed. VIB
VMware_bootbank_net-bnx2x_1.61.15.v50.1-2vmw.500.2.26.914586 cannot be live installed
. VIB VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.500.2.26.914586 cannot be live
installed. VIB VMware_bootbank_net-tg3_3.123b.v50.1-1vmw.500.2.26.914586 cannot be
live installed. VIB VMware_bootbank_esx-tboot_5.0.0-2.26.914586 cannot be live installed.
VIB VMware_bootbank_net-e1000e_1.1.2-3vmw.500.2.26.914586 cannot be live installed.
VIB VMware_bootbank_net-igb_2.1.11.1-3vmw.500.2.26.914586 cannot be live installed.
VIB VMware_bootbank_net-ixgbe_2.0.84.8.2-11vmw.500.2.26.914586 cannot be live
installed. VIB VMware_bootbank_net-e1000e_1.1.2-3vmw.500.1.11.623860 cannot be
removed live. VIB VMware_boofirewall.config.changed
Fehler
27.12.2012 07:32:39
srvesxicc02.comline.de

Hi,
welchge Version haben den die ESXi Server die du Updaten willst?? Und wie hast du versucht das Update einzuspielen?

Gruß Peter

PeterDA hat geschrieben:Hi,
welchge Version haben den die ESXi Server die du Updaten willst?? Und wie hast du versucht das Update einzuspielen?

Gruß Peter

Hallo,
oer Konsole und
esxcli software vib update --depot=/vmfs/volumes/vmware_files/esx50/update-from-esxi5.0-5.0_update02.zip
vorher Version 821926
Das Problem scheint reproduzierbar lösbar zu sein wenn ich vorher den Host einmal neu starte. Ich kann damit leben aber schön ist anders.
Gruss

Kann es sein, dass auf dem betroffenen Host das ESX auf einem USB-Datenträger installiert ist?

~thc hat geschrieben:Kann es sein, dass auf dem betroffenen Host das ESX auf einem USB-Datenträger installiert ist?

ja ????

Na liegt eventuell genau dort das Problem, wenn du dein Scratch- bzw Log-Verzeichnis nicht auf Storage oder DAS gesetzt hast.

Dayworker hat geschrieben:Na liegt eventuell genau dort das Problem, wenn du dein Scratch- bzw Log-Verzeichnis nicht auf Storage oder DAS gesetzt hast.

Hallo,

ich habe jetzt mit Hilfe von
http://kb.vmware.com/selfservice/micros ... Id=2003322
allen Servern einen Syslogserver eingetragen.
Daten laufen dort jetzt auch ein.
Kann ich noch mehr machen?
Mit dem Logging von ESX5 habe ich micht noch nicht beschäftigt.

Gruß und Dank

Ich vermute, dass dein ESX-Host den USB-Datenträger einfach aushängt. Der Host läuft zwar ungerührt weiter, aber (mindestens) zwei Sachen gehen bis zum nächsten Reboot nicht mehr: Das Installieren von VMWare Tools in VMs und das Patchen des Hosts.

Da die Maschine davon bootet und das RootFS darauf liegt, kann er den Datenträger nicht dismounten.

Ich habe das mit einem vom USB Stick gebooteten ESXi 5 selbst absichtlich gemacht und das geht. Dabei fliegen /bootbank, /altbootbank, /store und /scratch still und heimlich aus dem System - der Host verliert die Fähigkeit, zu patchen (bootbank), die VMTools zu installieren (store) und Logs zu schreiben (scratch). Das ESXi-root-FS ist eine RAMDisk.

~thc hat geschrieben:Ich habe das mit einem vom USB Stick gebooteten ESXi 5 selbst absichtlich gemacht und das geht. Dabei fliegen /bootbank, /altbootbank, /store und /scratch still und heimlich aus dem System - der Host verliert die Fähigkeit, zu patchen (bootbank), die VMTools zu installieren (store) und Logs zu schreiben (scratch). Das ESXi-root-FS ist eine RAMDisk.

Ok,

das würde passen aber ich habe die Sticks definitiv nicht abgezogen.
Die Frage wäre jetzt ob es reicht
vfat 4.0G 25.6M 4.0G 1% /vmfs/volumes/4b33278f-0d2df78e-fd71-00199905117a
zu überwachen und ggf. wieder zu mounten.

Gruss

Filesystem Size Used Available Use% Mounted on
NFS 18.9T 12.9T 6.1T 68% /vmfs/volumes/backup01
NFS 7.2T 1.4T 5.7T 20% /vmfs/volumes/storage_iso
NFS 7.2T 1.4T 5.7T 20% /vmfs/volumes/vmware_files
VMFS-3 1.1T 905.5G 258.3G 78% /vmfs/volumes/datastore01
VMFS-3 69.5G 41.6G 27.9G 60% /vmfs/volumes/system
vfat 249.7M 126.8M 122.9M 51% /vmfs/volumes/e912f3e8-fc05e8d0-3630-3e4d8b2576d6
vfat 249.7M 126.9M 122.8M 51% /vmfs/volumes/6af147e6-d3dd8982-e305-e931ab7d2329
vfat 285.8M 193.2M 92.6M 68% /vmfs/volumes/5044a0c6-c355c035-cf74-000c296b46f3
vfat 4.0G 25.6M 4.0G 1% /vmfs/volumes/4b33278f-0d2df78e-fd71-00199905117a
vfat 249.7M 88.1M 161.7M 35% /vmfs/volumes/Hypervisor1
vfat 249.7M 99.2M 150.5M 40% /vmfs/volumes/Hypervisor2
vfat 285.9M 135.9M 150.0M 48% /vmfs/volumes/Hypervisor3

Da du bei einem USB-"Verlust" alle vier vfat-Volumes verlierst, sollte als Überwachung eines der vier reichen. Mounten müsste man dann aber alle vier. (Was sind denn die zusätzlichen drei vfat-Volumes?)

@ ~thc
Schau dir mal die Laufwerksgrössen genauer an und du wirst eine Doppelung mit Hypervisor1, 2 und 3 feststellen. Über SSH oder SCP siehst du jedoch, daß die 3 als Hypervisor bezeichneten Laufwerke nur Hardlinks sind. Ich war darüber auch gestolpert, als ich meine ESXi-VMs mal durchstöbert hatte.