Hallo,
ich hab eine VM gelöscht (von Festplatte löschen). Die der VM zugeordnete vmdk-Datei wurde nicht gelöscht. Das muß ja bedeuten, irgendeiner anderen VM ist diese vmdk-Datei auch noch zugeordnet.
Wie finde ich diese VM? Muß ich wirklich alle VM's bzw. alle vmx-Dateien durchschauen?
Danke und Gruß
Martin
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Welche VM hat eine bestimmte vmdk-Datei zugeordnet?
-
- Member
- Beiträge: 185
- Registriert: 24.02.2005, 11:09
-
- King of the Hill
- Beiträge: 12942
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Ob eine VMDK aktiv genutzt wird sollte man ueber ihr Datei/Aenderungsdatum herausbekommen. Wenn dies aktuell ist dann ist die vDisk in der Tat in einer aktiven VM eingehaengt.
Wie man aber diese VM bestimmt ist nicht ganz einfach
- Powershell Script welches die VMs durchgehts und auf die pyhs. Dateinamen der vDisk schaut
- Die rvTools unter Umstaenden weil diese per Default ein Inkonsistenzen Namne/Ordner "melden" hinten im vHealth Tab
- Ein for Loop auf der Shell des ESX mit grep der *.vmx nach dem Namen. Das ist bei Hosts im Cluster aber nicht ganz einfach weil die gesperrten *.vmx nen Fehler produzieren und nur den Zugriff vom ausfuehrenden Host erlauben
Gruss
Joerg
Wie man aber diese VM bestimmt ist nicht ganz einfach
- Powershell Script welches die VMs durchgehts und auf die pyhs. Dateinamen der vDisk schaut
- Die rvTools unter Umstaenden weil diese per Default ein Inkonsistenzen Namne/Ordner "melden" hinten im vHealth Tab
- Ein for Loop auf der Shell des ESX mit grep der *.vmx nach dem Namen. Das ist bei Hosts im Cluster aber nicht ganz einfach weil die gesperrten *.vmx nen Fehler produzieren und nur den Zugriff vom ausfuehrenden Host erlauben
Gruss
Joerg
Man kann auch ggfs. den Hinweisen aus dem KB-Artikel folgen, und versuchen, den Host, von dem die vmdk gelockt sein koennte zu idenitfizieren.
Auf diesem fuehrt man dann aus.
Wenn schon der KB-Artkel keinen Hinweis auf den Host bringen sollte, dann ist vmtl. der Hinweis auf den Lock Owner verlorengegangen. Dann hilft eigentlich, die Hosts alle der Reihe nach zu rebooten.
Auf diesem fuehrt man dann
Code: Alles auswählen
grep -i <vmdk-name> /vmfs/volumes/*/*/*.vmx
Wenn schon der KB-Artkel keinen Hinweis auf den Host bringen sollte, dann ist vmtl. der Hinweis auf den Lock Owner verlorengegangen. Dann hilft eigentlich, die Hosts alle der Reihe nach zu rebooten.
-
- Member
- Beiträge: 185
- Registriert: 24.02.2005, 11:09
Das Änderungsdatum der vmdk ist Oktober 2014. Die Datei dürfte also nicht in einer laufenden VM hängen.
Mit "find / -name *.vmx | grep Name_der_vmdk_Datei"
wird nichts gefunden.
Ich hab dann versucht, die Datei manuell zu löschen
"vmkfstools -U Name_der_vmdk_Datei"
und die Meldung bekommen "device or ressource busy".
Vielleicht läuft einfach grade der Löschvorgang.
Mit "find / -name *.vmx | grep Name_der_vmdk_Datei"
wird nichts gefunden.
Ich hab dann versucht, die Datei manuell zu löschen
"vmkfstools -U Name_der_vmdk_Datei"
und die Meldung bekommen "device or ressource busy".
Vielleicht läuft einfach grade der Löschvorgang.
Schau' doch lieber mal, welche Dateien noch im VM-Verzeichnis vorhanden sind, und loesche die dann einzeln per rm -f.
Es kann auch sein, dass noch irgendeiner die -ctk festhaelt. Der vmkfstools-Befehl versucht, saemtliche Bestandteile der vmdk (Descriptor, flat-file, etc.pp.) zusammen zu bearbeiten; deswegen ist das so nicht hinreichend aussagekraeftig.
Es kann auch sein, dass noch irgendeiner die -ctk festhaelt. Der vmkfstools-Befehl versucht, saemtliche Bestandteile der vmdk (Descriptor, flat-file, etc.pp.) zusammen zu bearbeiten; deswegen ist das so nicht hinreichend aussagekraeftig.
-
- King of the Hill
- Beiträge: 12942
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
Wenn das Datum vom Oktober ist dann koennte es sich
- Um die Basis VMDK Datei handeln und die VM lief seit dieser Zeit auf einem Snapshot
- Es ist eine Leiche aus frueheren Tagen
Wenn ein ESXi warum auch immer noch nen Lock drauf haelt wuerde das die Busy Meldung erklaeren. Da hilft in den meisten Faellen nur ein Host reboot. Ist das ein Standalone ESXi mit Lokalstroage oder nen Cluster mit SAN?
Gruss
Joerg
- Um die Basis VMDK Datei handeln und die VM lief seit dieser Zeit auf einem Snapshot
- Es ist eine Leiche aus frueheren Tagen
Wenn ein ESXi warum auch immer noch nen Lock drauf haelt wuerde das die Busy Meldung erklaeren. Da hilft in den meisten Faellen nur ein Host reboot. Ist das ein Standalone ESXi mit Lokalstroage oder nen Cluster mit SAN?
Gruss
Joerg
-
- Member
- Beiträge: 185
- Registriert: 24.02.2005, 11:09
Es sind 2 ESX-Server mit FC-SAN dahinter.
In dem Verzeichnis sind nur 2 Dateien (name.vmdk und name-flat.vmdk). Wenn es von der vmdk Snapshots geben würde, wären die doch im gleichen Verzeichnis, oder?
Ich hab mal beide Dateien umbenannt. Das ging. Anschliessend versucht zu löschen mit rm, das ging bei name.vmdk, jedoch nicht bei name-flat.vmdk. Immer noch device or ressource busy.
Komisch. Umbenennen sollte doch auch nicht gehen, wenn sie im Zugriff ist.
Werd jetzt mal die ESXen nacheinander booten. Es ist unsere alte vSphere-Umgebung. Dort laufen nur noch eine handvoll VM's
In dem Verzeichnis sind nur 2 Dateien (name.vmdk und name-flat.vmdk). Wenn es von der vmdk Snapshots geben würde, wären die doch im gleichen Verzeichnis, oder?
Ich hab mal beide Dateien umbenannt. Das ging. Anschliessend versucht zu löschen mit rm, das ging bei name.vmdk, jedoch nicht bei name-flat.vmdk. Immer noch device or ressource busy.
Komisch. Umbenennen sollte doch auch nicht gehen, wenn sie im Zugriff ist.
Werd jetzt mal die ESXen nacheinander booten. Es ist unsere alte vSphere-Umgebung. Dort laufen nur noch eine handvoll VM's
Wie oben schon mit Hinweis auf den KB geschrieben:
Probier' doch mal mit vmkfstools -D zu ermitteln, ob der "lockende" Host errmittelt werden kann. Dann sollte es ausreichen, diesen zu rebooten.
Ich hab' bei mir momentan eine -ctk.vmdk Datei, die ich zwar nicht loeschen, aber problemlos in andere Verzeichnisse verschieben kann. Es gibt da Dinge manchmal...
Probier' doch mal mit vmkfstools -D zu ermitteln, ob der "lockende" Host errmittelt werden kann. Dann sollte es ausreichen, diesen zu rebooten.
Ich hab' bei mir momentan eine -ctk.vmdk Datei, die ich zwar nicht loeschen, aber problemlos in andere Verzeichnisse verschieben kann. Es gibt da Dinge manchmal...
-
- King of the Hill
- Beiträge: 12942
- Registriert: 02.08.2008, 15:06
- Wohnort: Hannover/Wuerzburg
- Kontaktdaten:
AlbertMinrich hat geschrieben:Es sind 2 ESX-Server mit FC-SAN dahinter.
In dem Verzeichnis sind nur 2 Dateien (name.vmdk und name-flat.vmdk). Wenn es von der vmdk Snapshots geben würde, wären die doch im gleichen Verzeichnis, oder?
Ja, aber das wuerde das Fehlerbild erklaeren. Der Snapshot ist der aktive Teil welchen deine VM verwendet hat bis du sie ausgeschaltet und geloescht wurde. Die Basis VMDK ist scheinbar in Benutzung oder gelocked und ist somit ueber geblieben.
In Umgebungen wo zum Backup die Hot-Add Methode verwendet wird tritt es haeuefiger mal auf das die Basis VMDK der Backup Appliance zugeordnet bleibt und somit nen Snapshot stehen bleibt und die Original VM halt lustig mit dem Snapshot weiterarbeitt und auch nur dieser in der *.vmx drin steht.
Gruss
Joerg
-
- Member
- Beiträge: 185
- Registriert: 24.02.2005, 11:09
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste