Vier Zeichen, die nach einem VMware-Bug aussahen
Ein befreundeter Dienstleister rief an. Sein Kunde: ein Betrieb mit rund fünfzig Leuten, drei ESXi-Hosts an einem Dell-Storage, kein vCenter. Ein Datastore war voll und sollte vergrößert werden. Das Volume auf dem Storage war schon erweitert, jetzt fehlte nur noch der Schritt im Host Client.
Die Oberfläche nahm die neue Größe entgegen, meldete Erfolg — und am Datastore kam nichts an.
Der Kollege hatte sich beholfen, wie man sich behilft: neue Volumes angelegt statt das alte zu erweitern. Das funktionierte sofort. Aber es erklärte nichts, und irgendwann wollte er wissen, warum.
Die Fährte, die zu gut passte
Wer das Symptom in eine Suchmaschine tippt, findet innerhalb von Minuten einen echten, dokumentierten Fehler: ESXi 6.7 kann beim Erweitern eines VMFS-Datastores mit „cannot parse a long value" abbrechen. Es gibt einen Knowledge-Base-Artikel dazu, Forenbeiträge, und einen Workaround per SSH mit partedUtil, bei dem man die Partitionstabelle von Hand nachzieht.
Alles passte. Gleiche Version, gleiches Symptom, gleiche Ratlosigkeit in den Foren. Ich hatte die Befehlsfolge schon offen.
Was mich gerettet hat, war Faulheit. Bevor ich per SSH an einer Partitionstabelle herumschneide, wollte ich den Fehler noch einmal in der Oberfläche sehen. Also die Maske aufgemacht und die Zahl langsam eingetippt, Ziffer für Ziffer.
Nach der vierten Ziffer nahm das Feld keine weitere an.
Vier Zeichen
Auf der Verwaltungsstation lief ein Firefox, der seit rund drei Jahren keine Updates gesehen hatte. Auf dieser Station renderte der Host Client nicht falsch, sondern fast richtig — und das ist schlimmer. Das Eingabefeld für die neue Gesamtgröße in Gigabyte war da, es sah normal aus, es nahm Zeichen an. Nur eben nicht mehr als vier.
Die gewünschte Größe hatte fünf Stellen. Wer die Zahl blind tippt und auf Weiter klickt, sieht nicht, dass die letzte fehlt. Abgeschickt wurde also eine Gesamtgröße, die kleiner war als die aktuelle. Warum der Assistent das nicht abgefangen hat, kann ich nur vermuten — die Prüfung der Eingabe läuft im Browser, und auf diesem Browser lief offenbar auch sie nicht mehr richtig. Ergebnis: nichts. Erfolgsmeldung: ja.
Aktuellen Browser installiert, Zahl eingegeben, erweitert. Storage-Rescan, fertig. Kein SSH, kein partedUtil, kein Neustart.
Bei Weboberflächen zuerst den Browser wechseln. Dann erst die Knowledge Base.
Warum man trotzdem zuerst zur Knowledge Base greift
Der dokumentierte Fehler war die bessere Erklärung. Er war spezifisch, er war belegt, er hatte einen Namen. Ein veralteter Browser ist dagegen eine langweilige Erklärung, die auf alles passt und deshalb nach nichts klingt. Wer zwischen einer präzisen und einer banalen Ursache wählen kann, nimmt die präzise — weil sie sich wie Kompetenz anfühlt.
Nur kostet die präzise Lösung hier etwa eine Stunde per SSH an einer Partitionstabelle, mit einem Risiko, das man dem Kunden eines Freundes nicht erklären möchte. Der Browserwechsel kostet ein paar Minuten. Deshalb die Reihenfolge: erst die Tests, die nichts kaputt machen können — Browser wechseln, Rechner wechseln, Benutzer wechseln. Bleibt das Symptom, ist die Knowledge Base dran. Bleibt es nicht, hat man sich den Rest gespart.
Was die Umgebung noch erzählt hat
Der Browser war ein Symptom. Die Umgebung hatte viele Jahre einen internen Administrator, der wenig dokumentierte, und danach einen früheren externen Dienstleister, der ebenfalls wenig dokumentierte. Kein vCenter, obwohl die Lizenz eines hergegeben hätte. Dateifreigaben über Dutzende einzelne Berechtigungen statt über Gruppen. Und eine Verwaltungsstation, auf der eben seit Jahren niemand mehr etwas aktualisiert hatte.
In so einer Umgebung ist die banale Erklärung fast immer die richtige. Der zweite Fall aus derselben Fernwartung — ein SAN-Switch, der seit Monaten in einer Bootschleife hängt, ohne dass es jemand als Ausfall behandelt — bekommt einen eigenen Beitrag.