Workstation - content ID ändern

[gRoot]

Guten Morgen zusammen,

ich habe ein Problem mit einem älteren Windows 7 Rechner.
Auf diesem PC läuft VMware Workstation und darin eine Win7 VM.

Die VM lässt sich nicht mehr einschalten, es taucht immer die selbe Fehlermeldung auf. (siehe Anhang)
Ich habe in den vergangenen Tagen sehr viel recherchiert und rumprobiert, bekomme sie dennoch nicht zum Laufen..

Ich habe gelesen, dass man die "parentCID" einer .vmdk verändern kann, leider weiß ich aufgrund meiner mangelnden Erfahrung in dem Bereich
nicht, wie ich das machen kann..

Falls jemand einen Lösungsvorschlag hat, gerne her damit.

Wünsche eine angenehme Restwoche.

[irix]

Hab zwar keine Workstation und auch selber das Problem nun so noch nicht gehabt aber da steckt folgendes dahinter. Da du eine VM(vDisk) mit Snapshots hast muss VMware versuchen zu ueberwachen das die ganze auf sich aufbauende Dateikette konsistent bleibt.

Bei jedem start der VM oder Inbetriebnahme einer vDisk(vmdk) schreibt und aendert er die ContentID durchgehend fuer die ganze Kette. So kann er pruefen ob die Kette halbwegs plausibel ist.

Ich meine das die ContentID (CID) im Hex Format angegeben ist und du kannst die einfach auf 0 bzw. F0F0F0F0 (passende Laenge vorher mal gucken) setzen in dem du den kleinen VMDK Descriptor mit dem Editor (Notepad++,UE) aufmachst und aenderst. Der Windows Editor kann mangels Newline Support (Zeilenumbruch) evtl. nicht gehen.

Das ganze ist nicht VMware Workstation spezifisch sondern betrifft vSphere ESXi auch da der Mechanismus der gleich ist.

Die Frage aber warum es aus einander gelaufen ist.... weil mit der manuellen Aenderung ueberlistet du nur die Validierung und die VM laesst sich starten. Es schuetzt nicht vor Datenmuell wenn sich die Base VMDK deiner Snapshotkette tatsaechlich geaendert hat. Das passiert immer dann sehr leicht wenn einer anderen VM ausversehen oder mit Absicht die vDisk zugeordnet wurde.

Edit:
Ansonsten poste mal ein Dateilisting und den Inhalt eines jeden Descriptors.


Gruss
Joerg

[gRoot]

Moin,

weshalb es auseinander gelaufen ist, kann ich leider nicht sagen.. lies sich einfach nicht mehr starten und es folgte eine Fehlermeldung nach der anderen.

anbei ein Screenshot, von allen Dateien im Ordner der VM.
Kann mit dem Editor leider keine vmdk. öffnen.

Viele Grüße
Chris

[gRoot]

Hallo,

gerade nochmal nachgeschaut, die "Windows 7 x64-0-000002.vmdk", also die kleinste lässt sich öffnen.

[JustMe]

Leider arbeitet die Workstation (meist) mit monolithischen Dateien, und nicht wie der ESXi mit einer gesplitteten vmdk aus einem (grossen) Daten- und einem (kleinen, leicht editierbaren) Deskriptorteil.

Aber die gewuenschte Information findest Du ja auch so in den Dateien:
Dort gibt es immer die CID (der aktuellen Datei) und die ParentCID (der "Eltern"-Datei). Und diese Verlinkung ist bei Dir aufgrund einer unbedachten Bearbeitung der Snapshots auseinander gedriftet.

Zur Korrektur benoetigst Du nun einen Binaer-Editor, wie z.B. HxD.

Damit lassen sich einerseits auch grosse Dateien oeffnen, und dann auch gleich die CIDs in der Kette so anpassen, dass sie wieder zueinander passen.

Ob man mit den Daten der dann wieder einschaltbaren VM was anfangen kann (und ob das Windows7 darin noch starten kann), steht auf einem ganz anderen Blatt.

Auf jeden Fall solltest Du SAEMTLICHE Aenderungen und weiteren Tests AUSSCHLIESSLICH an Kopien der jetzt vorliegenden Dateien anstellen, damit man wenigstens immer wieder auf dem aktuellen Stand aufsetzen kann, falls was schieflaeuft.

Viel Glueck!

[gRoot]

Hallo,

erstmal vielen lieben Dank für die Hilfe.
Konnte mit dem Hex-Editor alle .vmdk's aufmachen und die Werte anschauen.
Ich habe eine kleine Liste erstellt, mit allen VMDK's und den dazugehörigen CID's sowie parentCID'S.

Ich habe diese nach Dateinnamen aufgeteilt, macht wahrscheinlich keinen Sinn, da Sie alle irgenwie zusammenhängen..
Hat jemand einen Tipp, wie ich den Zusammenhang besser verstehen kann?

[JustMe]

Ui, das sieht etwas merkwuerdig aus... hilft aber im Weiteren bestimmt noch.
Aber lade doch bitte noch die beiden kleinen Dateien Windows 7 x64.vmx (Konfigurationsinformation der VM) und Windows 7 x64.vmsd (Beschreibung der Snapshots) hoch.

Ich vermute mal, dass Du an Deiner VM zwei VMDK haengen hast: Windows 7 x64.vmdk und Windows 7 x64-0.vmdk (und deren jeweilige Snapshots).
Hast Du Dir sicherheitshalber immer genau notiert, WAS Du WANN probiert/geaendert hast?

Ach ja:
Sobald Dir ein Hex-Editor zur Verfuegung steht, braucht's auch die Dateianfaenge aller 6 vmdk-Dateien (so 2KB sollten reichen).

[gRoot]

Was haben die Dateien denn zu bedeuten?

Es gibt einmal Windows 7 x64.vmdk
dazu die -000001 + 000002.vmdk

Dann gibt es die Windows 7 x64-0.vmdk
dazu die -000001 + 000002.vmdk

Kann es sein, dass dies verschiedene Partitionen innerhalb dieser VM sind?

Viele Grüße
Chris

[JustMe]

S.o.

Sehr merkwuerdig ist aber, dass die ParentCID von Windows 7 x64-000002.vmdk auf Windows 7 x64-0.vmdk zu verweisen scheint.

Deshalb der Wunsch nach den Anfaengen aller 6 Dateien.

[gRoot]

Hier die .vmx :

Code: Alles auswählen

.encoding = "windows-1252"
config.version = "8"
virtualHW.version = "10"
numvcpus = "4"
cpuid.coresPerSocket = "4"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsisas1068"
sata0.present = "TRUE"
memsize = "6144"
mem.hotadd = "TRUE"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "Windows 7 x64-000001.vmdk"
sata0:1.present = "TRUE"
sata0:1.fileName = "auto detect"
sata0:1.deviceType = "cdrom-raw"
ethernet0.present = "TRUE"
ethernet0.virtualDev = "e1000"
ethernet0.wakeOnPcktRcv = "FALSE"
ethernet0.addressType = "generated"
usb.present = "TRUE"
ehci.present = "TRUE"
ehci.pciSlotNumber = "35"
sound.present = "TRUE"
sound.virtualDev = "hdaudio"
sound.fileName = "-1"
sound.autodetect = "TRUE"
mks.enable3d = "TRUE"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "TRUE"
hpet0.present = "TRUE"
usb.vbluetooth.startConnected = "FALSE"
displayName = "Engelke Win 7 x64"
guestOS = "windows7-64"
nvram = "Windows 7 x64.nvram"
virtualHW.productCompatibility = "hosted"
powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"
extendedConfigFile = "Windows 7 x64.vmxf"
uuid.bios = "56 4d 21 b9 0f 95 61 78-db 1e 3f 4b 3b 39 c7 dc"
uuid.location = "56 4d de 33 3b 5d ff 2a-15 27 d5 40 3f 17 fb 20"
replay.supported = "FALSE"
replay.filename = ""
scsi0:0.redo = ""
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
scsi0.pciSlotNumber = "160"
usb.pciSlotNumber = "32"
ethernet0.pciSlotNumber = "33"
sound.pciSlotNumber = "34"
vmci0.pciSlotNumber = "36"
sata0.pciSlotNumber = "37"
scsi0.sasWWID = "50 05 05 69 05 96 bd 20"
ethernet0.generatedAddress = "00:0c:29:77:89:8b"
ethernet0.generatedAddressOffset = "0"
vmci0.id = "1058536224"
monitor.phys_bits_used = "40"
vmotion.checkpointFBSize = "134217728"
cleanShutdown = "TRUE"
softPowerOff = "TRUE"
usb:1.speed = "2"
usb:1.present = "TRUE"
usb:1.deviceType = "hub"
usb:1.port = "1"
usb:1.parent = "-1"
sata0:1.autodetect = "TRUE"
tools.syncTime = "FALSE"
unity.wasCapable = "FALSE"
tools.remindInstall = "FALSE"
toolsInstallManager.updateCounter = "1"
gui.fullScreenAtPowerOn = "TRUE"
gui.lastPoweredViewMode = "fullscreen"
scsi0:1.present = "TRUE"
scsi0:1.fileName = "Windows 7 x64-0-000001.vmdk"
scsi0:1.redo = ""
floppy0.present = "FALSE"
usb.autoConnect.device0 = ""
checkpoint.vmState = ""
usb:0.present = "TRUE"
usb:0.deviceType = "hid"
usb:0.port = "0"
usb:0.parent = "-1"
fileSearchPath = "E:\ENGELKE_WIN7_64;."


hier die .vmsd :

Code: Alles auswählen

.encoding = "windows-1252"
snapshot.lastUID = "9"
snapshot.needConsolidate = "TRUE"
snapshot.mru0.uid = "9"
snapshot.mru1.uid = "7"


Tut mir Leid, was meinst du genau mit den Anfängen der 6 Dateien?
Der Part, der mit #Disk DescriptorFile anfängt?

[JustMe]

Wie vermutet:

Code: Alles auswählen

scsi0:0.fileName = "Windows 7 x64-000001.vmdk"
scsi0:1.fileName = "Windows 7 x64-0-000001.vmdk"


Das sind zwei (virtuelle) Festplatten. Die Partitionierung erfolgt dann AUF diesen beiden Festplatten; d.h. es muessen (und werden sicherlich) nicht ausschliesslich C: und D: darauf liegen.

Naechste Merkwuerdigkeit ist, dass Dein abgebildeter Dateianfang von "Windows 7 x64-0-000002.vmdk" anzeigt, dass die -000002.vmdk auf die -000001.vmdk verweist, die Deine .vmx aber als Ende der Snapshotkette vermerkt.

Hast Du vielleicht Anfang der Woche mit Snapshots experimentiert?

"Dateianfang" ist wie beschrieben: so 2KB an binaeren Daten. Die kannst Du z.B. mit HxD abschneiden, und in einem .zip hier hochladen.

[gRoot]

Es gab zu dieser VM 2 Snapshots, diese waren von 2017 und 2019.
Habe diese Anfang der Woche gelöscht, da diese nicht mehr notwendig waren.
Die beiden Snapshots wurden über den Snapshot-Manager innerhalb von VMware Workstation entfernt.

Ich habe diese beiden Snapshots allerdings noch als Datei auf einer ext. Platte.. wüsste aber nicht ob das hilft.

Ich bin wirklich seit mehreren Tagen schon dabei, möchte einfach nur noch, dass die VM wieder anspringt..

anbei hoffentlich die gewünschten Dateien.

[JustMe]

Tja, hm, wenn die VM aber nur mit dem Datenbestand von 2017 anspringt, waer's vmtl. auch nicht so toll...

Liegen die Dateien alle zusammen im Verzeichnis E:\ENGELKE_WIN7_64 ?
Kannst Du aus der Erinnerung noch sagen, WIE VIELE Festplatten Dein Win7 gesehen hat (nicht Partitionen, sondern wirklich Platten)? Und vielleicht auch, in welcher Groesse?

Leider scheint es ja keine aelteren Logdateien mehr zu geben; die fehlgeschlagenen Startversuche haben haben alles getilgt.

Insgesamt scheinen momentan beide Snapshotketten auf dieselbe Basisdatei zu zeigen, und das kann selbstverfreilich nicht klappen.

Seltsam erscheinen mir die Dateigroessen. Da hat jede Snapshot-VMDK mehrere Gigabyte, was eigentlich bedeutet, dass sie einige Zeit mit Schreibzugriffen (denn nur die landen ja in der Snapshot-Datei) gelaufen sind.

Hast Du wie vorgeschlagen ALLE Dateien schon einmal zur Sicherheit irgendwo hin kopiert?
Danach kannst Du nur schauen, dass Du die zweite Platte aus der VM-Konfig entfernst, und sukzessive die Snapshotketten ausprobierst. Soll heissen:
- zuerst nur "Windows 7 x64.vmdk" als scsi0:0 in die .vmx eintragen. Damit sollte sich die VM einschalten lassen (aber mit einem ganz alten Stand).
- Danach dann einen Snapshot nach dem anderen dranhaengen (also jeweils wieder die Basis.vmdk in das Verzeichnis zurueckkopieren, die Snapshotdatei als scsi0:0 in die .vmx eintragen, die CIDs so anpassen, dass sie aufeinander aufbauen: Als ParentCID die CID der Eltern-Datei in die Snapshot-vmdk eintragen).

Das wird aber eine ziemliche Bastelei und Kopiererei. Das muss man wirklich wollen, aber ich nehme einfach mal an, dass Du keine Sicherung vorliegen hast...

[JustMe]

Ach so, PS:
Wenn Du gaaaaaaaaaaaaaanz grosses Glueck hast, dann koennte es auch sein, dass der Snapshot-Loeschvorgang (fast) fertig war, und tatsaechlich die Snap-Infos schon wieder in der Basis-Datei liegen. Aber das wuerde ich eigentlich nicht zu hoffen wagen...

[gRoot]

Leider weiß ich nichts von den Festplatten und deren Größen etc, da ich den PC für jemand anderen "repariere".

Die Dateien liegen alle zusammen im Verzeichnis E:\ENGELKE_WIN7_64.
Oder konntest du aus der .vmx oder sonstigen Dateien einen falschen Pfad entnehmen?

Eine ältere Logdatei gibts leider nicht..

Gesichert habe ich alles seperat auf einer ext. Festplatte.


Die beiden Snapshots auf meiner Platte heißen wie folgt:
Windows 7 x64-Snapshot7.vmsn (von 09.10.2017)
Windows 7 x64-Snapshot9.vmsn (von 23.04.2019)

Beide Dateien sind auch nur "31KB" groß.
Diese muss ich dann eintragen?

Es gibt leider keine Sicherung, sonst wäre das auch zu einfach..

[gRoot]

Ich hatte die Maschine am Dienstag mit einem Stand von 2019 zum Laufen bekommen.. fehlen leider 2 Jahre und deswegen versuche ich mein Glück weiter.

Aber ich denke mal, wenn ich sie erstmal wieder zum Laufen bekomme, ist das schonmal ein guter Anfang.

[JustMe]

Die beiden .vmsn-Dateien tauchen in Deiner abgebildeten Dateiliste aber nicht auf...

Und die musst Du auch nirgends eintragen. Ich habe doch davon geschrieben, die .vmdk jeweils in der .vmx einzutragen.

Hast Du noch die Dateien von VOR Deinem Start am Dienstag in 2019? Dann wuerde ich auf jeden Fall alles Weitere mit diesen vorherigen Dateien (bzw. deren Kopien!) angehen, denn jeder auch nicht so ganz erfolgreiche Windows-Start veraendert Informationen auf der dann aktiven .vmdk.

Das Verzeichnis sollte OK sein. Es ist aber aussergewoehnlich, dass in der -0.vmdk die Parent-Datei mit absolutem Pfad eingetragen ist, und sich in der .vmx auch noch ein Eintrag zu diesem Pfad findet. Das braucht's normalerweise halt nicht, wenn immer alles nur in einem gemeinsamen und identischen Pfad verwendet wird.

[Dayworker]

Ich komme mit "Windows 7 x64" und "Windows 7 x64-0" sowie den vielen Dump-Dateien im Verzeichnisabbild im Erstposting nicht so recht vorwärts.Geklärt...

Dump-Dateien werden immer nach schwerwiegenden Problemen bzw Abstürzen einer VM geschrieben. Kann es sein, daß da mal mehrere Win7-VMs im selben Verzeichnis gespeichert waren? Alternativ wurde einer bestehenden VM eine reparaturbedürftige VMDK untergeschoben und bei der VMDK-Auswahl bekommt man ja nur die Parent/Basis- aber nie die Child/Snapshot-VMDK angezeigt. Allein dadurch würde man die Basis-VMDK bereits verändern und die Fehlermeldung im Erstposting verursachen. Das könnte dann auch den absoluten Pfad nach Laufwerk "E" in der VMX-Datei erklären können.


Ich würde den Gedanken, mit dem Dateistand anfangen BEVOR die Snapshots gelöscht wurden, angehen. Bei der Gelegenheit könnte man auch nochmal in die alten Log-Dateien reinschauen.

[gRoot]

Guten Morgen,

wenn ich die .vmdk nicht mal mounten kann, da ein schwerwiegender Fehler aufgetreten ist, ist die .vmdk dann komplett nutzlos?
Normalerweise könnte man Sie doch mounten und so auf die Daten zugreifen..

[JustMe]

Welche .vmdk willst Du auf welche Art & Weise mounten?
Die Snapshot-VMDKs lassen sich grundsaetzlich nicht einzeln bearbeiten, da sie ja nur die Aenderungen zur jeweiligen Eltern-VMDK enthalten.
Also versucht das VMware-Produkt, die Snapshot-Kette (die mit den Deskriptoren verfolgt wird) komplett abzuarbeiten, und wenn es dabei zu einem Problem kommt, dann wird halt ein schwerwiegender Fehler ausgegeben...

[gRoot]

Schönen guten Morgen,

ich habe mich gestern nur noch auf die Datenrettung fokussiert. Ich konnte mit dem Tool "StarWind V2V" die .vmdk in eine .vhd umwandeln,
jetzt kann ich die ehemals "defekte" .vmdk ganz normal öffnen und die Daten auslesen.

Ich möchte mich ganz herzlichst bei allen für die Hilfe bedanken, konnte eine Menge dazu lernen.

Viele Grüße
Chris