VMware-Forum

Hallo Leute,

Hatte gestern bei nem Kunden nen Crash eines ESXi. Zufällig als ich genau da war und was komplett anderes machen musste. Wurden dann ein paar h mehr.

Sympthome:
- VM's wurden Lahm
- NFS-Storage Verbindung zur Storage VM wurde gekappt
- VM's liefen in IO-Überlauf
- Die Storage VM lief nur noch auf Sparflamme und reagierte kaum mehr. Die NFS Shares konnte sie nicht mehr bereitstellen.

Nach dem abwürgen aller VM's, inkl. schweren Herzens auch der Storage VM - Sie beherbergt das Software RAID, also eher eine heikle Angelegenheit wenn noch so viele IO's offen sind - wollte der Host nimmer neu starten.
Ursache: USB-Stick bzw. Teile davon im Eimer (Partitiontabelle war noch intakt, bootloader auch, dann war fertig)

Behebung: Nun, keine grosse Sache. Neuer USB-Stick, Neu installiert und konfiguriert und alles lief sauber weiter. Software-RAID nahm keinerlei Schaden.
--> LSI-SAS-HBA durchgereicht mit Einzel-SSD's

Jetzt zur Frage:
Mir ist das irgendwie unlogisch, warum läuft der ESXi nicht sauber weiter nur weil der USB-Stick am Arsch ist?
Und viel wichtiger, ist PCI-Passtrough vielleicht sogar davon abhängig, dass das Installations-Medium vorhanden ist?

Dann müsste ich nämlich meine Praxis überdenken (tu ich vielleicht eh) und wieder zurück auf gespiegelte Festplatten wechseln. Auch wens Perle vor die Säue ist. Aber sowas möchte ich ned nochmal erleben nur weil der USB Stick die Grätsche macht. Da ist jede Festplatte billiger. Neuinstallation wenn er bei kontrolliertem Neustart ned hochkommt ok, VM's im laufenden Betrieb nur wegen USB-Stick abzuschiessen finde ich dagegen ned so prall.

Thanks

Da ist ein typischer Fall von "Kommt darauf an.".

Dein USB-Bootmedium enthält keine Scratch-Partition. Damit sind nur bootbank, altbootbank und locker eingehängt, auf die eigentlich nur beim Patchen schreibend zugegriffen wird.

Man kann (bei meinen Tests) im laufenden Betrieb das USB-Medium auch herausziehen, ohne das der ESXi sich jetzt groß daran stört - du könntest das mal im Labor mit Passthrough probieren.

Der Kernel überprüft regelmäßig die USB-Busse und wenn dein Stick jetzt diese Kommunikation entscheidend stört, kann er sich natürlich verhaspeln.

Das mit dem Labor ist so eine Sache. Meine Laborumgebung war zu gut, jetzt ist sie produktiv.

Allerdings hab ich noch ne alte Mühle die ich evtl. dafür hernehmen könnte.


Was mir noch einfällt: Ich habe eine VM neu registriert gehabt am gleichen Tag. Evtl. wollte er ja anschliessend auf den Stick schreiben und hat sich so weggehängt? Dürfe aber eigentlich auch ned sein.

Das ist ein guter Einwand von dir - durch die Änderung der Konfiguration muss /bootbank/state.tgz (die Konfiguration) neu geschrieben werden - das kann dann den Fehler provoziert haben.

So wirklich happy bin ich mit dem verhalten aber ned... Ist das normal?

Ab 5.5 besser?

Oder gibt es eine Möglichkeit es zu merken bevor man Änderungen macht?

Ob der Kernel in Bezug auf USB bei 5.5/6.0 entscheidende Veränderungen aufweist, kann dir nur ein Entwickler sagen. Du kannst natürlich vor jeder Änderung der Konfiguration oder jedem Patch erst mal prüfen, ob der Stick noch lesbar ist (z.B. im vSphere-Client beim Einhängen einer ISO nach den Tool-ISOs schauen) oder alle Logs konsultieren. Aber ob das dann solche Fehler ausschließt, möchte ich bezweifeln.

Meine Empfehlung: lokale S-ATA-Disk oder kleines RAID-Volume zum Booten benutzen.

OT: Letztens hatte sich bei einem Auftraggeber von mir der virtuelle Hauptserver aus dem Netz verabschiedet, weil eine (durchgereichte) USB-Festplatte ausgetauscht worden war. Nach ca. 25 Minuten war er dann wieder von allein wieder da. Im Nachhinein lies sich feststellen, dass die VMs unbeirrt weitergelaufen waren und nur diverse Dienste des ESXi hingen (scheinbar auch die vSwitches) und irgendwann vom ESXi ohne äußere Eingriffe neu gestartet wurden.

Als hier der USB Stick Schwierigkeiten machte gabs nen Alarm im vCenter. Mangels Zeit war der ESXi noch 3 Wochen in Produktion bis wie ihn ausgeschaltet und auf einem neuen Stick installiert haben.

2 USB Sticks und 0 SD Karten sind bis Dato defekt gegangen in den 3 Jahren.

Gruss
Joerg

@irix: Habt Ihr diese im oder ausserhalb des Gehäuses?

Wenn die Leute nicht so unbedarft wären, würde ich sie ja ausserhalb einstecken...

Allerdings sind die Doms in den Supermicro-Gehäusen direkt dem Luftstrom ausgesetzt und nicht der Nähe von den heissen Teilen. Würde wohl nix ändern bzw. verschlimmern, da die USB-Ports aussen bei den Lüftungsausgängen der CPU sind.