VMware-Forum

Hallo zusammen,

habe derzeit ein kleines Problem beim lösen von Snapshots.

sofern ich die Snapshots über den VC lösen möchte läuft dieser in einen Timeout Fehler.

Seltsam ist das über den Snapshot Manager nur ein Snaphost angezeigt wird und rein von den Files her müsste es 5 Stück sein.

-rw------- 1 root root 16M Jan 2 17:37 FILE01-000002-delta.vmdk
-rw------- 1 root root 278 Jan 2 17:31 FILE01-000002.vmdk
-rw------- 1 root root 16M Dec 22 01:03 FILE01_1-000001-delta.vmdk
-rw------- 1 root root 252 Jan 2 16:39 FILE01_1-000001.vmdk
-rw------- 1 root root 16M Dec 17 17:09 FILE01_1-000002-delta.vmdk
-rw------- 1 root root 283 Dec 16 15:32 FILE01_1-000002.vmdk
-rw------- 1 root root 30G Jan 2 17:30 FILE01_1-000003-delta.vmdk
-rw------- 1 root root 259 Jan 2 16:39 FILE01_1-000003.vmdk
-rw------- 1 root root 133G Jan 2 16:39 FILE01_1-000004-delta.vmdk
-rw------- 1 root root 259 Dec 27 17:36 FILE01_1-000004.vmdk
-rw------- 1 root root 16M Jan 2 17:37 FILE01_1-000005-delta.vmdk
-rw------- 1 root root 233 Jan 2 17:31 FILE01_1-000005.vmdk
-rw------- 1 root root 300G Dec 21 17:54 FILE01_1-flat.vmdk
-rw------- 1 root root 342 Jan 2 16:39 FILE01_1.vmdk
-rw-r--r-- 1 root root 37 Sep 24 16:31 FILE01-37a1b97f.hlog
-rw------- 1 root root 1.0G Dec 27 17:36 FILE01-37a1b97f.vswp
-rw------- 1 root root 10G Jan 2 16:39 FILE01-flat.vmdk
-rw------- 1 root root 8.5K Dec 27 17:36 FILE01.nvram
-rw------- 1 root root 18K Jan 2 16:39 FILE01-Snapshot34.vmsn
-rw------- 1 root root 338 Jan 2 16:39 FILE01.vmdk
-rw------- 1 root root 545 Jan 2 16:39 FILE01.vmsd
-rwxr-xr-x 1 root root 1.8K Jan 2 16:39 FILE01.vmx
-rw------- 1 root root 250 Jan 1 18:26 FILE01.vmxf
drwxr-xr-x 1 root root 1.1K Jan 2 17:00 phd
-rw-r--r-- 1 root root 18K Dec 17 17:14 vmware-10.log
-rw-r--r-- 1 root root 21K Dec 17 17:16 vmware-11.log
-rw-r--r-- 1 root root 93K Dec 27 08:52 vmware-12.log
-rw-r--r-- 1 root root 353K Dec 13 08:59 vmware-7.log
-rw-r--r-- 1 root root 77K Dec 17 17:09 vmware-8.log
-rw-r--r-- 1 root root 18K Dec 17 17:14 vmware-9.log
-rw-r--r-- 1 root root 75K Jan 2 17:37 vmware.log

kann ich diese auch über den Befehl vmware-cmd *.vmx removesnapshot lösen
wichtig ist Natürlich ohne DatenVerlust.


Bin für jedes Feedback dankbar.


Grüße
MaierCH

Hi,
tjaja,, die Snapshots....

zuerst einmal: welchen Datenverlust willst Du vermeiden?
Brauchst Du den aktuellen Zustand der VM?

Musst Du zu irgendeinem Snapshot wieder zurückspringen können?

Ansonsten müsste es über vmware-cmd removesnapshots gehen, ohne dass der aktuelle Zustand der VM verändert wird (evtl. dauert das aber eine Weile, und die VM friert wärenddessen ein!).
Dabei werden die Deltas dann in die Originale .vmdk-Datei commited...

Auf keinen Fall darfst Du natürlich die delta-dateien einfach so löschen, das gibt Datenverlust !!

edit: Ach ja, für weitere Recherche und Hintergrundinfos:
http://vmware-forum.de/viewtopic.php?p= ... =ahl#37230
und
http://vmware-forum.de/viewtopic.php?p= ... =ahl#37878
der ist evtl. auch noch interessant:
http://vmware-forum.de/viewtopic.php?t=8561

Viele Grüße,
Jörg

Hey,

ja ich brauche den aktuellen Stand der VM sonst geht mir die Produktion für die nächsten Tage .

Danke für die Info´s


MaierCH

Hallo,
ich hatte das Problem bei einem Kunden von mir auch schon mal.
Folgende Sachen solltest du tun.
Schau ob das Datastore, auf dem die VM mit den Snapshots noch genug Speicher frei hat!
Verbinde dich direkt mit dem ESX Server und nicht mit dem Virtual Center.
Fahre dann die VM herunter und entferne dann den Snapshot.
Dann warte je nachdem einige Minuten bis Stunden, bis der Snapshot gelöscht wird.

Halo Bomboletti,

danke fürs Feedback, leider läuft auf der MSA die Platten voll (nur noch 30 GB frei)

das Snapshot, worauf es annkommt, belegt derzeit schon 133 GB

rw------- 1 root root 133G Jan 2 16:39 FILE01_1-000004-delta.vmdk

ein Backup Script ist leider in ein Fehler reingelaufen und hat den Snapshot nicht mehr gelöst, leider hat es auch keiner gemerkt

werde Morgen die VM runter fahren und die Snapshot´s mittel vmware-cmd löschen.

133GB kann denke ich können ganz schön lange dauern!!


MFG

MaierCH

ja, für die 133GB kannst Du einige Zeit einkalkulieren. Habs mit so großen Deltas noch nie probiert, aber ich denke, dass es durchaus einige Stunden dauern kann....

Viel Erfolg / Glück!!

Eine kurze Erfahrungsmeldung wäre schön, kannst ja die Stoppuhr mitlaufen lassen (Und trink nicht zuviel Kaffee währenddessen )

Grüße,
Jörg

wie groß darf eigentlich das Snapshot werden ohne das es mir um die Ohren fliegt.

Danke

MaierCH

Mir wäre nicht bekannt, dass es da eine maximale Größe gibt. Natürlich können die delta-Dateien maximal so groß werden wie die originale Platte (wenn sich jeder Block auf der Platte geändert hat). Oder der Platz auf der VMFS-Partition ausgeht, das ist dann mit Datenverlust verbunden.
VMware empfiehlt, drauf zu schauen dass die deltas max. ca. 1 GB groß werden, aber da bist Du ja schon langge drüber.

Es dauert halt um so länger, den Snapshot zu löschen/committen...

Viele Grüße,
Jörg

PS.: Backup der Daten von innerhalb des Gastes aus übers NEtzwerk vor der Aktion ist natürlich unbedingt empfehlenswert!

Hallo,

ich werde warten biis ich ein vollständiges Backup habe und werde es dann nochmal versuchen die Snapshots über vmware-cmd zu committen.

Falls das nicht funktioniert werde ich die vmdk händisch löschen und die Daten übers Backup wieder restaurieren.

Das ist denke ich der sichere und evtl. auch der schnellere Weg .

Danke

Grüße

MaierCH

Gestern Abend hatte ich mich dazu überreden lassen das Snapshot zu löschen.
Diese Aktion ist nach ner halben Stunde in einen Timeout gelaufen, leider musste ich auch feststellen das dieser Prozess die letzten GB auf meiner MSA ausgefüllt hatte.

werden beim comitten des Snapshots die Daten erst einmal Temporär auf die Platten weggeschrieben ???? oder woher kam auf einmal der Platzverlust ???

Grüße

MaierCH

Je nachdem, wie Du den "Remove Snapshot Task" gestartet hast und abhängig, welche Version vom ESX und VC Du verwendest, wird vor dem eigentlichen Committen ein neuer Snapshot erstellt.
(Um das "Einfrieren" der VM während des ganzen Vorgangs möglichst kurz zu halten.)

Wenn sich nun während Deines Tasks viel auf der Platte verändert hat, kann es sein, dass der neue Snapshot das Volume vollaufen lies.

Viele Grüße,
Jörg

irgentwie habe ich im Moment richtig Bauchw....
ich hoffe das Snapshot fliegt mir nicht um die Ohren wenn ich erst einmal noch ein paar Tage warten muß biss ich eine Downtime für den Server bekomme.

Ich hoffe die zusätzlichen GB halten sich in Grenzen.

Hat schonmal jemand schlechte Erfahrung mit Snapshots gemacht ????


Danke

MaierCH

MaierCH hat geschrieben:irgentwie habe ich im Moment richtig Bauchw....
ich hoffe das Snapshot fliegt mir nicht um die Ohren wenn ich erst einmal noch ein paar Tage warten muß biss ich eine Downtime für den Server bekomme.

Ich hoffe die zusätzlichen GB halten sich in Grenzen.

Hat schonmal jemand schlechte Erfahrung mit Snapshots gemacht ????


Danke

MaierCH

Ja, hier sind die schlechten Erfahrungen. Grund für dei schlechten Erfahrungen ist zu wenig freier Speicherplatz (nicht zugewiesener) gewesen. So dass die Snapshots insgesamt zu groß geworden sind und die Platte komplett zu gemacht haben.
Lösung war beim letzten mal: Virtuelle Windows Maschine löschen und Snapshot dann Löschen. Glücklicherweise hat dieses mal geklappt. Was man beim ersten Fehler nicht unbedingt sagen konnte (Datenverlust).
So wie ich das hier lese hast Du genau das gleiche Problem wie ich damals hatte.

Das die Deltafiles größer werden ist ja klar. Ich denke Du arbeitest ungefähr in einem solchen Zenario:
Snapshot 1 --> Snapshot 2 --> Snapshot 3 --> Snapshot 3 usw.
Wenn Du jetzt Snapshot 3 löschen möchtest, dann wachsen die anderen natürlich an.

Ich wünsche viel Glück.

Hallo,


kann ich die SystemDisk des Servers über vmkfstools - i clonen ohne das Snapshot Informationen mit übertragen werden ??

Den Datenträger D:\ hol ich mir wieder über das Backup zurück.



Danke

Chris

Nimm doch einfach ghost - wie bei echtblech auch.
Boote die VM in bartpe oder ghost und speicher das Image irgendwo im Netzwerk ...