VMware-Forum

Hallo,

bei einer VM ist irgendwie die Snapshots völlig schief gelaufen. Diese VM hat nun bereits über 17 Snapshots liegen die VM über die GUI auch nicht mehr anzeigt.

Die bekannten Tricks wie neuen Snapshot anlegen und dann alle löschen, oder Maschine einmal aus dem Bestand entfernen und wieder hinzufügen hilft alles nicht.

Nun gäbe es ja noch die Möglichkeit mit vmkfstools -i snapshot-00017.vmdk konsolidiert.vmdl zu machen, aber ich kann doch nicht 17 Snapshots zu konsolidieren oder muss man nur den letzten?

Wenn man den letzten mit der angegebenen Kommandozeile zu vmkfstools auswaehlt, werden selbstverstaendlich alle "dazwischen" liegenden mit in die neue vmdk konsolidiert.

Das heißt dann nur noch die vmx datei danach anpassen und dann gehts weiter?
Aber es ginge doch reintheoritisch auch wenn ich über den vSphere Client einfach die Maschine klone oder?

Ja und ja.

Und nicht vergessen, die alten Dateien zu loeschen.

Da aber Cloning erwaehnt wurde:
Beim direkten Bearbeiten der .vmx beachten, dass die VM dazu aus der Bestandsliste des vCenters entfernt ist. Anscheinend gibt's da ge"cache"te Daten in der vCenter-DB, die nach einem Veraendern der .vmx auf Kommandozeile einfach die alten Daten aus dem DB-Cache spaeter wieder auf die Platte nageln.

@Justme,

aus diesem Grund startet man die VM auf dem Host von der cmd und nicht ueber den vSphere Client bzw. restartet den vpxa welcher aktuelle Daten dann zum vCenter schickt.

In diesem Fall aber nicht notwendig da nach dem manuellen Cloning der VMDK in eine neue man diese auch ueber die GUI hinzufuegen kann. Sprich einfach die vorhandenen vDisks aushaengen mit Hilfe des Clients und dann die neue hinzufuegen mittels "select existing disk".

Anschliessend im Verzeichnis aufraeumen.

Gruss
JOerg

Das Klonen hat gut funktioniert. Alle Snapshot weg.
Jedoch ist eine vmdk übrig, von der alten Maschine, die sich nicht löschen lässt, weder per GUI noch per SSH.

rm: can't remove 'vm-ctk.vmdk': Device or resource busy

@irix: Viele Wege fuehren nach Rom (oder sonstwo)

@Cr4sh: Die -ctk gehoert zum Change Block Tracking. Die duerfte eigentlich nicht allzu gross sein. Aber damit das Verzeichnis sauber ist: Probier' doch mal, ob Du durch Ausschalten des CBT per Enabling Changed Block Tracking (CBT) on virtual machines die Datei von ihrem Lock befreien kannst. Schau' Dir ggfs. auch dies von heute an. Evtl. hilft sonst auch ein Reboot des Hosts als letzte Massnahme.

Also das CBT geht nicht da es die virtuelle Maschine nicht mehr gibt.

Und ein Neustart des Hosts hat leider auch nicht geholfen, die Datei ist immer noch nicht löschbar. Ich habe ein vCenter mit 3 Hosts. Hatte jetzt nur den Hosts neugestartet wo die Maschine lag.

Tja, hmmm, ....

Ist die ctk-Datei die letzte Datei im Ordner? D.h. es wird nur noch die geclonte VM in ihrem eigenen (anderen) Verzeichnis verwendet? Wie sieht's aus, wenn die geclonte VM mal auf einen anderen Host migriert wird?
Man koennte jetzt mit Investigating virtual machine file locks on ESXi/ESX untersuchen, von welcher MAC-Adresse die Datei gesperrt ist, aber leider ergibt das viel zu oft die MAC-Adresse 00:00:00:00:00:00.

Vmtl. gibt's Leute, die mit ein paar geschickten esxcli-Aufrufen herausfinden koennen, welcher Prozess auf welchem Host die Datei nutzt, und diesen Prozess dann abschiessen koennen. Leider gehoere ich nicht dazu; deswegen ist mein Latein hier zu Ende, sorry.

Genau die ctk Datei ist die letzte in diesem Ordner.
Das zweite stimmt auch das nur noch die geclonte im neuen Ordner verwendet wird.

Die ctk Datei lies sich nun löschen. Jedoch lässt sich der Ordner immer noch nicht löschen. Wenn ich auf der Konsole nun ein ls mache kommt:

ls: ./maschine.vmdk~: No such file or directory

bei ls -la :

ls: ./webshop.vmdk~: No such file or directory
drwxr-xr-x 1 root root 420 May 28 08:49 .
drwxr-xr-t 1 root root 5040 May 28 06:25 ..

und lösch versuch des Ordner:

/vmfs/volumes/52cbaa1b-0b306538-fefa-a0369f1cb6b1 # rm -R maschine
rm: can't remove 'maschine/maschine.vmdk~': No such file or directory
rm: can't remove 'maschine': Directory not empty

Ich sehe aber die vmdk~ nicht mal scheint ja eine Temp oder so zu sein?

Das Problem wurde gefunden, es war Acronis!