.:Ewig Drohendes Versagen:.

Ich klage mal wieder mein Leid über „Geister Snapshots“

Über die Feiertage ist bei einer unserer VMs ein Snapshot stehen geblieben
und da ich auch den einen oder anderen Tag Urlaub bekommen habe, ist das nicht gleich aufgefallen.

Auf jeden Fall war er mittlerweile 60GB groß. Das löschen via GUI hat mal wieder nicht funktioniert.
Irgendwann hat er abgebrochen und im VI Client wurde kein Snapshot mehr angezeigt.
Aber das kennen wir ja schon -> Lösung

Diesmal hat das aber nicht funktioniert – nach 12h ist der Vorgang abgebrochen und der Snapshot war immer noch da.

Netter weise ließ sich die VM aber auch nicht mehr einschalten (Schweißperlen bilden sich auf der Stirn des Admins)

Fehlermeldung:

The parent virtual disk has been modified since the child was created
Super – das kann ja ein toller Samstag werden!

Ich werde hier jetzt mal meinen Lösungsansatz schildern:

IST:

60G Jan 16 10:02 SERVER-XY_1-000001-delta.vmdk
256 Jan 15 17:09 SERVER-XY_1-000001.vmdk
7.2G Jan 15 18:24 SERVER-XY_1-000002-delta.vmdk
263 Jan 15 17:09 SERVER-XY_1-000002.vmdk
6.2G Jan 15 17:02 SERVER-XY_1-000003-delta.vmdk
263 Jan 14 08:59 SERVER-XY_1-000003.vmdk
302K Jan 15 17:05 SERVER-XY_1-000004-delta.vmdk
237 Jan 15 17:05 SERVER-XY_1-000004.vmdk
16M Jan 16 20:35 SERVER-XY_1-000005-delta.vmdk
263 Jan 16 11:34 SERVER-XY_1-000005.vmdk
150G Jan 16 08:58 SERVER-XY_1-flat.vmdk
405 Jan 16 11:30 SERVER-XY_1.vmdk

Durch den einen oder anderen Rettungsversuch unter der Woche haben wir jetzt schon 5 Snapshots – aber ob 2 oder 5 ist ja egal.
Eine Lösung findet sich im VMWare KB1007849

Hier mal die „cat´s“ meiner vmdk Files:

[root@esx SERVER-XY]# cat SERVER-XY_1-000005.vmdk
# Disk DescriptorFile
version=1
CID=e33002b5
parentCID=e33002b5
createType="vmfsSparse"
parentFileNameHint="SERVER-XY_1-000004.vmdk"
# Extent description
RW 314572800 VMFSSPARSE "SERVER-XY_1-000005-delta.vmdk"

# The Disk Data Base
#DDB

[root@esx SERVER-XY]# cat SERVER-XY_1-000004.vmdk
# Disk DescriptorFile
version=1
CID=e33002b5
parentCID=e33002b5
createType="vmfsSparse"
parentFileNameHint="SERVER-XY_1-000003.vmdk"
# Extent description
RW 314572800 VMFSSPARSE "SERVER-XY_1-000004-delta.vmdk"

# The Disk Data Base
#DDB

[root@esx SERVER-XY]# cat SERVER-XY_1-000003.vmdk
# Disk DescriptorFile
version=1
CID=e33002b5
parentCID=6d3da253
createType="vmfsSparse"
parentFileNameHint="SERVER-XY_1-000002.vmdk"
# Extent description
RW 314572800 VMFSSPARSE "SERVER-XY_1-000003-delta.vmdk"

# The Disk Data Base
#DDB

ddb.toolsVersion = "7303"
[root@esx SERVER-XY]# cat SERVER-XY_1-000002.vmdk
# Disk DescriptorFile
version=1
CID=6d3da253
parentCID=d35ad50b
createType="vmfsSparse"
parentFileNameHint="SERVER-XY_1-000001.vmdk"
# Extent description
RW 314572800 VMFSSPARSE "SERVER-XY_1-000002-delta.vmdk"

# The Disk Data Base
#DDB

ddb.toolsVersion = "7303"
[root@esx SERVER-XY]# cat SERVER-XY_1-000001.vmdk
# Disk DescriptorFile
version=1
CID=d35ad50b
parentCID=fee0d339
createType="vmfsSparse"
parentFileNameHint="SERVER-XY_1.vmdk"
# Extent description
RW 314572800 VMFSSPARSE "SERVER-XY_1-000001-delta.vmdk"

# The Disk Data Base
#DDB

ddb.toolsVersion = "7303"
[root@esx SERVER-XY]# cat SERVER-XY_1.vmdk
# Disk DescriptorFile
version=1
CID=e33002b5
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 314572800 VMFS "SERVER-XY_1-flat.vmdk"

# The Disk Data Base
#DDB

ddb.toolsVersion = "7303"
ddb.adapterType = "lsilogic"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "255"
ddb.geometry.cylinders = "19581"
ddb.uuid = "60 00 C2 92 aa ab 87 6b-72 50 9a 5a e3 99 fc 6b"
ddb.virtualHWVersion = "4"

Nach 5x drüber schauen habe ich das Problem auch gefunden.
Zuerst dachte ich mit dem Snapshot 4 stimmt was nicht,
da die CID und die parentCID gleich sind e33002b5
und dies auch noch die CID von Snapshot 3 ist.

Nach ein bissel probieren habe ich festgestellt, dass dies auftritt, wenn die VM nach dem Erstellen des Snapshots nicht eingeschaltet wurde (keine Änderungen am Snapshot vorgenommen wurden)

Gut das ist also nicht das Problem …

Wenn man sich jetzt aber das vmdk von der Basis HDD anschaut:

[root@esx SERVER-XY]# cat SERVER-XY_1.vmdk
# Disk DescriptorFile
version=1
CID=e33002b5
parentCID=ffffffff
createType="vmfs"

Dann fällt einem auf das die CID die selbe wie von Snapshot 3 ist
Das die parentCID fffffffff ist, ist OK – zeigt einfach das es kein weiteres Parent gibt.

[root@esx SERVER-XY]# cat SERVER-XY_1-000003.vmdk
# Disk DescriptorFile
version=1
CID=e33002b5
parentCID=6d3da253

da kann also was nicht stimmen…
Wenn man sich jetzt aber den Snapshot 1 anschaut:

[root@esx SERVER-XY]# cat SERVER-XY_1-000001.vmdk
# Disk DescriptorFile
version=1
CID=d35ad50b
parentCID=fee0d339

Hier sollte als Parent ja eigentlich die CID der Basis HDD stehen.
Nun ist die Frage – was ist falsch.
Die CID der Basis HDD oder die parentCID von Snapshot 1.

Zu Gunsten des Angeklagten habe ich angenommen, dass die CID der Basis HDD nicht stimmt und gegen die parentCID von Snapshot 1 getauscht.
Sieht dann also so aus:

[root@esx SERVER-XY]# cat SERVER-XY_1-000001.vmdk
# Disk DescriptorFile
version=1
CID=d35ad50b
parentCID=fee0d339
createType="vmfsSparse"
parentFileNameHint="SERVER-XY_1.vmdk"

[root@esx SERVER-XY]# cat SERVER-XY_1.vmdk
# Disk DescriptorFile
version=1
CID=fee0d339
parentCID=ffffffff
createType="vmfs"

Und siehe da – die VM bootet wieder
„Schweiß von der Stirn wischen“

Aber das Problem ist ja noch nicht vom Tisch …
Der Snapshot ist immer noch da. Bei mir war das „Glück“ das der Snapshot der System HDD schon committed war und nur noch die Daten HDD das Problem darstellte.

Zwei Lösungen denke ich mal gibt es:
1. 3te HDD in die VM und die Daten rüber kopieren (robocopy)
2. die VHD clonen

vmkfstools -i /vmfs/volumes/LUN1/SERVER-XY/SERVER-XY_1-000005.vmdk /vmfs/volumes/LUN1/SERVER-xy_recovery/SERVER-XY_1.vmdk

und dann die orginal HDD gegen die geclonte HDD ersetzten.

Ich hab ersteres gemacht – und bin froh das alles wieder geht ….

LINKS:
VMWare KB1007849 Consolidating snapshots
VMWare KB935 Cloning an ESX Server Virtual Machine
VMWare KB1005228 … virtual disk with snapshot has the wrong CID
VMWare KB1007969 Committing snapshots generates a content ID mismatch error
vmwaretips.com
About Roy I
Malaysia VMware Communities Tips to recover Snapshot problem on VM

Tags: ESX

Der Beitrag wurde am Dienstag, den 19. Januar 2010 um 15:29 Uhr veröffentlicht und wurde unter EDV Probleme, ESX abgelegt. du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.