VMware-Forum

Ich bin gerade dabei, ein VMFS-Volume zu leeren, das ich anderweitig benötige. Dabei bin ich auf ein Verzeichnis gestoßen, in dem eine ...flat.vmdk und eine .vswp liegen, beide mit Datum vom 29.4. Zu der Flat-vmdk gibt es keine Metadaten-vmdk, und die vswp lässt sich keiner laufenden VM zuordnen; ein

liefert nichts zurück.

Dennoch kann ich beide Dateien weder über den Datastore-Browser noch in einer SC-Sitzung löschen (es kommt ein "Device or resource busy").

Wie finde ich heraus, was diese Dateien blockiert?

Grüße, Georg.

Hi Georg,

es gibt nen undokumentierten Parameter -D für die vmkfstools, der schreibt zusätzliche Infos in /var/log/vmkernel...

Infos dazu:
http://vi3.org/download/guides/english/ ... gFiles.pdf

Aber wie immer: Keine Garantie, ich weiß nicht, ob undokumentiert gleich unsupported bedeutet ... aber mal anschauen schadet wohl nicht..

Viele Grüße,
Jörg

Jörg, was würden wir hier bloß ohne dich machen...

Das war exakt die Vorgehensweise, um mein Problem zu löschen - nur wüßte ich jetzt allzu gerne, was dazu führte. Sei X der Name der Maschine. Ich hatte drei Verzeichnisse im VMFS: X, X_1 und X_2. Das sieht für mich danach aus, als ob X zweimal aus dem Inventory (aber nicht von der Platte) entfernt und unter gleichem Namen wieder angelegt worden sein könnte, wobei dann aber einiges schief gelaufen sein muss.

Das Verzeichnis X enthielt eine verwaiste Flat-VMDK, die ich löschen konnte. Verzeichnis X_1 enthielt die .vswp und die Flat-VMDK, die gelockt waren. Die Maschine X habe ich vor ein paar Tagen noch per sVMotion auf anderen Speicher gezogen, wonach das X_2-Verzeichnis weg war. Maschine X wurde heruntergefahren, die Locks waren immer noch da. Ich habe dann mit ps -elf gesehen, dass eine Maschine mit dem gleichen Anzeigenamen und der schon längst nicht mehr existenten X_1/X.vmx seit Ende April läuft, die ich dann mit der beschriebenen Methode gestoppt habe. Im VC tauchte das Duplikat gar nicht auf.

Denkbar wäre also, dass ich in einem Anflug von Wahnsinn den Inhalt des Verzeichnisse in einer Konsolensitzung per rm entsorgt habe (wie es mir bei einer früheren Gelegenheit schon einmal passiert ist). Ich glaube das aber nicht, weil die Maschine X zum Arbeitsbereich eines Kollegen gehört, wo ich das nicht so mit leichter Hand machen würde. Außerdem hätte ich durch die Meldung, dass die beiden besagten Dateien nicht gelöscht werden konnten, stutzig werden müssen.

Ich habe also keine Ahnung, was genau passiert ist, und es lässt sich wohl auch nicht mehr rekonstruieren... Es scheint mir aber ein Design-Problem zu sein, dass bei einer laufenden VM offenbar nur die Flat-VMDK und die vswp gelockt zu sein scheinen und der Rest einfach so geöscht werden kann...

Nochmals danke!

Georg.

Ich kann mich an zwei Fälle mit ähnlichen Auswirkungen erinnern:
Einmal (wie so häufig) unachtsames Umgehen mit Snapshots: Ne WM hatte nen Snapshot, und wurde dann auf Kommandozeile verschoben....

Und dann (das was ich bei Dir eher vermute) bei Problemen mit Storage VMotion (da wird sogar (laut VMware-Unterlagen) im Hintergrund ne Kopie der VM angelegt während des Verschiebens. Wenn da also zwischendrin was schiefgeht, kommts auch zu solch seltsamen Effekten...

Außerdem kriegt man das natürlich leicht selber hin, wenn man häufig Platten (also vmdk-Dateien) von einer VM "nur so provisorisch" mal schnell in ne andere VM mountet.

Um die Diskussion noch zu vervollständigen (vielleicht hilfts ja später mal einem Nutzer der Suchfunktion ):
Evtl. hättest Du auch mit vm-support -X bzw. vm-support -x die rausfinden und hart abschießen können.
(Das war bei mir im obigen ersten Fall die einzige Lösung vor nem Neustart des ESX, da gar keine Prozesse für die VM mehr in der Console liefen. ist aber schon länger har, war noch ESX3.0.0 glaub ich).



Viele grüße,
Jörg
PS.: freut mich natürlich immer, wenn ich mit so nem "Treffer" schnell helfen kann

Ne WM hatte nen Snapshot, und wurde dann auf Kommandozeile verschoben....

Was genau meinst du damit? Mein Kollege arbeitet gerne (für meine Begriffe ein wenig zu gern) mit Snapshots, und es gab zum fraglichen Zeitpunkt wohl eine Menge Clone-Aktionen, aber sicherlich über den VI-Client - genau kann er es leider nicht rekonstruieren.

Dass wir sVMotion auf diese Maschine losgelassen haben, kann ich mit hoher Wahrscheinlichkeit ausschließen.

Georg.

so, wie ich das rekonstruiert hab (Aussage des Admin: "Ich hab nix g'macht" wie immer... ):

Eine VM hatte nen snapshot und lief, während der Admin die VM auf der Kommandozeile mit mv verschoben hat. Da hats dann alle Dateien bis auf die letzten Deltas verschoben, und dabei hat sich dann irgendwie der hostd verschluckt.
Die VM war im Client als ausgeschaltet angezeigt, lief aber noch (war noch pingpar). und auch in der Konsole mit vmware-cmd und mit ps nicht auffindbar.

Aus Neugier hab ich versucht, das später zu rekonstruieren, habs allerdings nicht nochmal geschafft mutwillig.... (Wenn etwas kaputtgehen kann, dann kriegen das die User/Trainingsteilnehmer/Kollegen hin. Wenn etwas nicht kaputtgehen kann, dann genauso )

Viele Grüße,
Jörg