VMware-Forum

Hallo,
ich habe seit Ewigkeiten ein großes Verständnisproblem mit Snapshots. Seit 10 Tagen bin ich nun dabei mich intensiv damit zu beschäftigen, stoße aber an 3 Punkten an mein Grenzen.
Ich hoffe auf eure Hilfe. Leider habe ich keine Möglichkeit Screenhost hochzuladen, darum geht nur der Umweg über die Links, sorry

Ausgangspunkt bildet dieses Bild. Dazu gibt es 5 vmdk Dateien.
https://picasaweb.google.com/lh/photo/fpCvrHXdYO0xst7XAZAvka7IXLCk0t6tUltfKyEeMT0?feat=directlink

Mache ich im Snapshot Manager ein Delete für Freitag und Donnerstag schaut es danach so aus:
Im Manager:
https://picasaweb.google.com/lh/photo/NJKikrG1_caRdrTRsPsWUa7IXLCk0t6tUltfKyEeMT0?feat=directlink
Im Windows-Explorer:
https://picasaweb.google.com/lh/photo/KNRDOcRqa-_vr5ifuNV3E67IXLCk0t6tUltfKyEeMT0?feat=directlink

Frage 1:
Warum wird bei einer sequenziellen Löschung immer die letzte vmdk Datei größer. Rechnerisch müsste in der 0003.vmdk der Datenbestand von 004+005.vmdk enthalten sein.
Passt aber von der Dateigröße 0003.vmdk nicht. Durch Löschung der vorhergehenden Snapshots vergrößert sich die 003.vmdk Datei.
Ich denke aber, vmdk bzw. redologs sich feste und nicht veränderbare Dateien.
-------------------------------------------------------------------------------------------------------
Ausgangspunkt:

https://picasaweb.google.com/lh/photo/NJKikrG1_caRdrTRsPsWUa7IXLCk0t6tUltfKyEeMT0?feat=directlink

Wenn ich ein GoTo Dienstag mache, schaut das dann so aus
Im Manager:
https://picasaweb.google.com/lh/photo/IS4N6G5G16CVR-S7WIXLD67IXLCk0t6tUltfKyEeMT0?feat=directlink
Im Explorer:
https://picasaweb.google.com/lh/photo/gDpf1kUGl3aE1vBO1ggha67IXLCk0t6tUltfKyEeMT0?feat=directlink

Frage2:
Was ist mit der Datei 003.vmdk? Wo ist die geblieben?

Mache ich ein GoTo Mittwoch ist die 003.vmdk wieder da.

Danke für eure Hilfe

Hi!
Beim Löschen eines Snapshots werden die Deltas gemerged, d.h. Du kannst nicht mit irgendwelchen Größen rechnen.
(Nicht verwechseln mit echten Redo/Transaktions-logs bei nem Datenbankserver z.B.!)
Wenn sich also ein Block auf der virtuellen Platte öfters verändert hat, wird trotzdem nur einmal der aktuelle Stand in der letzten Delta-Datei gehalten.

Und zur zweiten Frage:
Bei nem GoTo werden immer die letzen Veränderungen zwischen dem letzen Snapshot und dem "you are here" gelöscht => die 0003 verschwindet.

leider ist die Nummerierung der delta-Dateien nicht nach der Zeit geordnet, sondern es wird immer die kleinste freie Nummer genommen. Wenn Du also mit GoTo hin- und herspringst, kannst durchaus vorkommen, dass ne kleinere nummer eigentlich neuere Daten beinhaltet.
In Deiner Schilderung "taucht" also die 00003 nicht "wieder auf", sondern wird neu angelegt.

Zum besseren Verständnis mach Dir klar: Ein Snapshot ist logisch gesehen eine Momentaufnahme zu nem bestimmten Zeitpunkt.
Die Dateien im Hintergrund beinhalten aber die Daten zwischen verschiedenen Snapshots, d.h. eine denkweise ... die und die Delta entspricht dem und dem Snapshot ist falsch.

Für weitere Recherchen: Ullis Homepage: www.sanbarrow.com ,zB. hier:
http://sanbarrow.com/vmdk-snapshots.html#top

Viele Grüße,
Jörg

Hallo Tschoergez,

erstmal vielen Dank für deine Antwort.
Dein Satz "...eine denkweise ... die und die Delta entspricht dem und dem Snapshot ist falsch. " hat so manche Frage bei mir gelöst.

Desweiteren habe ich mir deine Antwort bestimmt 5x durchgelesen und versucht diese anhand von Snapshot nachzuvollziehen.

Meine Bitte:
Kannst du nochmal meine laut gedachten (geschriebenen) Gedanken überprüfen und ggf. verbessern?
Ich habe zum besseren Verständnis nochmal Screenshots gemacht was ich meine.
Ich habe insgesamt 7 Screenshot angelegt. im Windows Explorer schaut das so aus:
https://picasaweb.google.com/lh/photo/7xqQ6RWn6MpszJqVpdzRWOJz3XWeRIGp7k0r8-t4aRc?feat=directlink

Dann 2x ein Delete gemachte; delete 7 und delete 6. Windows Explorer schaut das so aus
https://picasaweb.google.com/lh/photo/-xJruOljbD-wjhH-K7EpyeJz3XWeRIGp7k0r8-t4aRc?feat=directlink
Durch Löschen eines Snapshost verbindet sich die vmdk Datei des zu löschenden Snapshot mit der zuletzt geschrieben vmdk Datei (Delta Datei).
Dabei ist nicht die Nummer der Delta Datei ausschlaggebend sondern allein der Zeitstempel. Der aktuellste Zeitstempel spiegelt auch die aktuellste Delta wieder. Und das ist die 005.vdmk.
==> Richtig

Dann ein GoTo 2: Windows Explorer schaut das so aus
https://picasaweb.google.com/lh/photo/MvJMSJlknslHvd32RAXhDOJz3XWeRIGp7k0r8-t4aRc?feat=directlink
Springt man mit einem GoTo irgendwo in die Mitte der linearen Snapshot-Kette, gehen alle zuvor gemachten Änderungen verloren, d.h. die operative Delta (vmdk) wird gelöscht und eine neue vmdk entsteht.
Dabei geht Vmware nach dem Prinzip der „kleinsten zu vergebenen Nummer“ vor. Die 005.vmdk war die operative Delta, diese wird gelöscht und die nächst kleiner Zahl ist die 6, also ist die neue Delta 0006.vmdk.
==> Richtig

Und dann wieder ein GoTo 5: Windows Explorer schaut das so aus:
https://picasaweb.google.com/lh/photo/KrZ0EXd6V7I1cZWaKp7EceJz3XWeRIGp7k0r8-t4aRc?feat=directlink
Springt man mit einem GoTo wieder zurück, wird die 006.vmdk gelöscht und nun wird wieder die 005.vmdk gebildet, da 5 die kleinste zur Verfügung stehende Zahl ist.
===> Richtig

Frage:
Ist die zuletzt geschrieben vmdk Datei die Datei, die den Zustand „You are here“ widerspiegelt?
Anderes ausgedrückt, ist eine vmdk Datei mit dem aktuellsten Zeitstempel gleich die operative Datei

Bei Gedankenfehlern, bitte korrigiere mich.

Vielen Dank für deine Hilfe

Da verknoten sich ja die Gehirnwindungen

Nur so ein paar Anmerkungen:
- Da wo sich der Zeitstempel bei Aenderungen aktualisiert ist der momentane Stand was das Delta des Snapshots angeht.
- Da sich die Systemzeit durchaus mal aendern koennte ist es nicht Klug nach der Uhrzeit zu gehen. In den Descriptor Dateien ist jedes mal die Parent VMDK vermerkt so das man eine Kette vom Akuellen Stand zum Ursprung hat. Der aktuelle Stand ist das was in der *.vmx drin steht und von da aus dann Rueckwaerts
- Im vSphere Umfeld koennen 2 Delta Dateien fuer einen Snapshot existieren
- Im vSphere Umfeld gibts eine Meta Datei ueber Snapshots und zwar die *.vmsd. Gibts die unter der Workstation auch? Ist Plaintext also ruhig mal reingucken

Gruss
Joerg

Desweiteren habe ich mir deine Antwort bestimmt 5x durchgelesen und versucht diese anhand von Snapshot nachzuvollziehen.

Meine Bitte:
Kannst du nochmal meine laut gedachten (geschriebenen) Gedanken überprüfen und ggf. verbessern?
Ich habe zum besseren Verständnis nochmal Screenshots gemacht was ich meine.
Ich habe insgesamt 7 Screenshot angelegt. im Windows Explorer schaut das so aus:
https://picasaweb.google.com/lh/photo/7xqQ6RWn6MpszJqVpdzRWOJz3XWeRIGp7k0r8-t4aRc?feat=directlink

Dann 2x ein Delete gemachte; delete 7 und delete 6. Windows Explorer schaut das so aus
https://picasaweb.google.com/lh/photo/-xJruOljbD-wjhH-K7EpyeJz3XWeRIGp7k0r8-t4aRc?feat=directlink
Durch Löschen eines Snapshost verbindet sich die vmdk Datei des zu löschenden Snapshot mit der zuletzt geschrieben vmdk Datei (Delta Datei).
Dabei ist nicht die Nummer der Delta Datei ausschlaggebend sondern allein der Zeitstempel. Der aktuellste Zeitstempel spiegelt auch die aktuellste Delta wieder. Und das ist die 005.vdmk.
==> Richtig

Der Snapshot inklusiver aller vorhergehenden Snapshots enthalten nur die sich seitdem veränderten Daten der Ursprungsplatte. Alle unveränderten bzw in vorhergehenden Snapshots nicht enthaltene Daten werden immer aus der Ursprungsplatte gelesen.
Ein Delete/Löschen (von VMware falsch übersetzt und müßte eigentlich Merge/Zusammenführen lauten) von 7 pflegt die seitdem geänderten Daten in die 6 und dann abschließend in die 5 ein.

Dann ein GoTo 2: Windows Explorer schaut das so aus
https://picasaweb.google.com/lh/photo/MvJMSJlknslHvd32RAXhDOJz3XWeRIGp7k0r8-t4aRc?feat=directlink
Springt man mit einem GoTo irgendwo in die Mitte der linearen Snapshot-Kette, gehen alle zuvor gemachten Änderungen verloren, d.h. die operative Delta (vmdk) wird gelöscht und eine neue vmdk entsteht.
Dabei geht Vmware nach dem Prinzip der „kleinsten zu vergebenen Nummer“ vor. Die 005.vmdk war die operative Delta, diese wird gelöscht und die nächst kleiner Zahl ist die 6, also ist die neue Delta 0006.vmdk.
==> Richtig

Nein.
Bei einem Goto wird nichts gelöscht. Das Gastdateisystem nimmt nur den Zustand von 2 inklusive der darin erfaßten Änderungen auf die Basedisk ein und schreibt dann alle neuen Änderungen richtig in die kleinste als nächstes zu vergebene Nummer also die 6.

Und dann wieder ein GoTo 5: Windows Explorer schaut das so aus:
https://picasaweb.google.com/lh/photo/KrZ0EXd6V7I1cZWaKp7EceJz3XWeRIGp7k0r8-t4aRc?feat=directlink
Springt man mit einem GoTo wieder zurück, wird die 006.vmdk gelöscht und nun wird wieder die 005.vmdk gebildet, da 5 die kleinste zur Verfügung stehende Zahl ist.
===> Richtig

Nein.
Da bei einem GoTo nichts gelöscht wird, nimmt das Dateisystem den Zustand von 5 ein und schreibt alle darin auftretenden Veränderungen in die nächst kleinste, freie Nummer die 7.

Frage:
Ist die zuletzt geschrieben vmdk Datei die Datei, die den Zustand „You are here“ widerspiegelt?
Anderes ausgedrückt, ist eine vmdk Datei mit dem aktuellsten Zeitstempel gleich die operative Datei

Wenn du damit meinst, daß der Zustand "You are here" alle durch die Snapshotkette vorgegebenen Änderungen an der Basedisk enthält, dann ja.
Zeit ist relativ, wie Jörg schon sagte. Orientiere dich daher immer an der in jeder VMDK aufgeführten Parent-Disk. Alles andere zerstört die Snapshotkette und deine Daten sind weg.

Schau dir unbedingt mal den uralten Thread Snapshot als Process tree an.
In welches Konstrukt sowas enden kann, hat Ulli sehr schön in zwei Bildern illustriert.