"Plattencrash"

[Dreas]

Moin,

mir bleibt gerade nix anderes übrig als entweder die Platten zu löschen oder hier einen dieser Hilfe-Posts zu schreiben, die ich ja selbst so unerfreulich finde...

Meine VM unter WS 6.0.0 hatte eine System- und eine Datendisk. Nach einer Änderung an Partitionen der physikalischen Platte des Host ist die vmdk der Datenpartition verschwunden. Dieses Problem können wir hier wohl leider nicht lösen. Auch nicht, dass nicht alle Daten gesichert waren.

Vielleicht aber, dass ich die Systemplatte weiter benutzen kann, denn die sieht mir noch ok aus.
Erst später las ich, dass man sowas lieber nicht mehr mountet. Das klappt aber zunächst mal und der Inhalt der Platte sieht auf den ersten Blick gut aus.
Die Systemplatte hat einen Snapshot. Die größere vmdk (VM 8250.vmdk, 16GB) müsste dann der Snapshot sein, die deutliche kleinere (VM 8250-000001.vmdk, 3GB) die aktuellen Änderungen, ist das richtig?

Ich hatte einen alten Clon der VM und den Plan, der VM die Datenplatte mit gleichem Namen unterzuschieben. Beim Starten wird nun zwar nicht mehr die fehlende Datenplatte (VM 8250-M.vmdk) moniert, allerdings "Unable to open file "V:\VM 8250\VM 8250.vmdk": One of the disks in this virtual machine is already in use by a virtual machine or by a snapshot."
Ein LCK-Ordner mit LCK-Datei entsteht schon beim Öffnen (nicht Starten) der VM.

Warum blockieren sich die beiden System-vmdk's, was könnte da schief laufen?
Würde zu gern die Systempartition weiter benutzen.

Dreas

[Dayworker]

Da läuft in meinen Augen garnix schief. Sobald du eine VM öffnest, werden logischerweise die zugehörigen Datenträger gelockt oder macht es Sinn, im Vordergrund eine v.Disk zu löschen und genau diese v.Disk im Hintergrund zu starten?
Die WS verhindert das genauso, wie du eine offene v.Disk/VMDK darüber normalerweise nicht löschen kannst. Falls du sie doch löschst, ist sie zumindest noch solange auf der Platte vorhanden, bis du den Zugriff darauf beendest...

Die größere VMDK ohne Zahl mit vielen Nullen im Namen ist die normale v.Disk dieser VM und die 000001 enthält alle seitdem aufgelaufenen Änderungen. Bei einer 16GB VM-Disk und einem Snapshot von 3GB kann ich dir nur raten, diese regelmäßig einzupflegen. Denn ein Snapshot ist kein Backup, sondern nur ein Mittel dafür und Snapshots vereinfachen im Fehlerfall nicht unbedingt die Rettung. Zumal viele aus Unwissenheit oder einfach Ignoranz vor dem Manual dann auch noch Sparse-Disks (mitwachsende v.Disk's) einsetzen und sich dann über lahme VMs beschweren. Diese sollten besser einmal wöchentlich geshrinkt werden oder die v.Disk verteilt sich möglicherweise quer über die gesamte Host-Platte und die WS weigert sich einfach dann diese VM zu starten.

[continuum]

Versteh ich das richtig ?

Du gibst deiner VM VM 8250.vmdk als Platte 1 und VM 8250-000001.vmdk als Platte 2 ?

Wenn ja waere das ein grober fehler.

Die VM 8250-000001.vmdk ist der Snapshot von VM 8250.vmdk und beide zusammen bilden den letzten Stand.
Dabei muss dann in der VM VM 8250-000001.vmdk als aleinige Platte eingetragen werden.

[Dreas]

continuum,

so versteht es wohl die VM, eingestellt ist aber:
scsi0:0.fileName = "VM 8250-000001.vmdk"
ide0:1.filename = "VM 8250-M.vmdk"

Der Meldung nach wird ja die "VM 8250.vmdk" benutzt, aber wo?
Auch wenn ich die zweite Platte weglasse, gibt's die Meldung.

[continuum]

Hi
sobald du scsi0:0.fileName = "VM 8250-000001.vmdk"
verwendest wird automatuisch auch "VM 8250.vmdk" verwendet - das ist nun makl die Funktion bei snapshots.

Was du da machst ist im Klartext gesprochen grober Unfug.
Das kann nicht gehen

Was willst du genau erreichen ???

[McStarfighter]

Ein Snapshot ist schließlich nichts anderes als eine Differenzdatei, welche die Unterschiede zur Basisplatte (oder eventueller vorheriger Snapshot-Stande) speichert. Naja, und um die Unterschiede auch auswerten zu können, brauchts immer noch die Basisplatte. Daher wird die auch aktiviert und genutzt ...

[Dreas]

Sorry für die Verwirrung, ich habe aber die Einträge nicht wissentlich selbst erstellt und sie können durchaus momentan ziemlich sinnlos sein.

Ich möchte erreichen, dass ich zwei Platten habe, Daten + System.
Mit den vorliegenden 3 Dateien wie oben beschrieben ist das doch möglich, oder?

Auch wenn es euch trivial erscheint, was müsste ich an den Einstellungen ändern, damit es sinnvoll wird?

Ich frage auch deshalb so dumm, weil ich mit dem genannten alten Clon vergleiche, der immer noch rund läuft und m.E. über analoge Dateien (mit Zusatz -cl1) und Einstellungen verfügt.

[continuum]

Leider haben wir hier nicht genug Daten zu deiner VM vorliegen - zip mal die aktuelle vmx - alle kleinen vmdks und eine Dateiliste zusammen und lad das bei ifile.it hoch - dann sehe ich mal nach

[Dreas]

Klar, gern, danke

http://ifile.it/j3umkp2
Zum Vergleich der Clon "VM 8250 B": http://ifile.it/hwr9q85

Komischerweise auch nur eine einzige kleine vmdk.
Hab das Kapitel in deinem Handbuch noch nicht ganz durch, bedeutet aber, dass die discription am Anfang der großen vmdks liegt?

Jetzt gibt's bestimmt Haue. Die VM stammt aber ursprünglich vom Converter, laufen/liefen auch so und ich will hier keinen ärgern. Nicht erschrecken, wenn das alles nicht optimal aussieht!
Dankbar bin ich schon jetzt.

[Dayworker]

Jun 10 10:54:27.221: vmx| AIOWIN32: 'V:\VM 8250\VM 8250-000001.vmdk' : Failed to write: Es steht nicht genug Speicherplatz auf dem Datenträger zur Verfügung (112).
Jun 10 10:54:27.221: vmx| VMXAIOMGR: Retry on write "V:\VM 8250\VM 8250-000001.vmdk" : Es steht nicht genug Speicherplatz auf dem Datenträger zur Verfügung.
Jun 10 10:54:27.221: vmx| VMXAIOMGR: system : err=28674 errCode=112 freeSpace=49152
Jun 10 10:54:27.221: vmx| VMXAIOMGR: "V:\VM 8250\VM 8250-000001.vmdk" : write s=3686072320 n=65536 ne=1
Jun 10 10:54:27.221: vmx| VMXAIOMGR: v[0]=9813000:65536
Jun 10 10:54:27.221: vmx| Msg_Question:
Jun 10 10:54:27.221: vmx| [msg.vmxaiomgr.retryabort.diskfull] Operation on file "V:\VM 8250\VM 8250-000001.vmdk" failed (Es steht nicht genug Speicherplatz auf dem Datenträger zur Verfügung).
Jun 10 10:54:27.221: vmx| The filesystem where disk "V:\VM 8250\VM 8250-000001.vmdk" resides is full.
Jun 10 10:54:27.221: vmx| Choose Retry to attempt the operation again. Choose Abort to terminate the session.
Jun 10 10:54:27.221: vmx| ----------------------------------------
Jun 10 10:54:28.612: vmx| Msg_Question: msg.vmxaiomgr.retryabort.diskfull reply=1
Jun 10 10:54:28.612: vmx| Msg_Post: Warning
Jun 10 10:54:28.612: vmx| [msg.vmxaiomgr.corrupted] VMware Workstation cannot sync with disk before abort. Disk V:\VM 8250\VM 8250-000001.vmdk may be inconsistent.
Jun 10 10:54:28.612: vmx| ----------------------------------------
Jun 10 10:54:28.659: vmx| User requested abort: Exiting because of failed disk operation.

Ist doch eine eindeutige Sache.

Jun 10 10:54:14.409: vmx| DISK: OPEN scsi0:0 'V:\VM 8250\VM 8250-000001.vmdk' persistent R[(null)]
Jun 10 10:54:14.409: vmx| FILE: ScanDirectory discarding file 'V:\VM 8250\VM 8250-000001.vmdk.lck\M63669.lck'; invalid executionID.
Jun 10 10:54:14.581: vmx| DISKLIB-DSCPTR: Opened [0]: "VM 8250-000001.vmdk" (0xa)
Jun 10 10:54:14.581: vmx| DISKLIB-LINK : Opened 'V:\VM 8250\VM 8250-000001.vmdk' (0xa): monolithicSparse, 33593964 sectors / 16404 Mb.

monolithicSparse ist so mit das ungeschickteste, was man in der Virtualisierung machen kann. Zumindest wenn es performant sein und bleiben soll. Wenn deine VMs nicht regelmäßig geschrinkt werden, verweigert irgendwann die WS und kann die VMs nicht mehr starten.

Jun 10 21:56:26.562: vmx| Opened paging file M:\VM 8250 B\564d12e3-f86e-f2f2-dd86-37f168e1d4b4.vmem
Jun 10 21:56:26.593: vmx| DISK: OPEN ide0:1 'M:\VM 8250 B\VM 8250-M-cl1.vmdk' independent-persistent R[(null)]
Jun 10 21:56:26.796: vmx| DISKLIB-DSCPTR: Opened [0]: "VM 8250-M-cl1.vmdk" (0xa)
Jun 10 21:56:26.796: vmx| DISKLIB-LINK : Opened 'M:\VM 8250 B\VM 8250-M-cl1.vmdk' (0xa): monolithicSparse, 16777216 sectors / 8192 Mb.
Jun 10 21:56:26.796: vmx| DISKLIB-LIB : Opened "M:\VM 8250 B\VM 8250-M-cl1.vmdk" (flags 0xa). 9300044
Jun 10 21:56:26.796: vmx| DiskGetGeometry: Reading of disk partition table
Jun 10 21:56:26.812: vmx| DISK: OPEN 'M:\VM 8250 B\VM 8250-M-cl1.vmdk' Geo (16383/16/63) BIOS Geo (1044/255/63) freeSpace=14162Mb, ide

Gib es eigentlich einen trifftigen Grund, weshalb du als VM-Speicherort ausgerechnet die als chronisch unzuverlässig bekannten VMware-SharedFolder, also Laufwerk M:\ bei dir, ausgewählt hast

[Dreas]

Jun 10 10:54:28.612: vmx| [msg.vmxaiomgr.corrupted] VMware Workstation cannot sync with disk before abort. Disk V:\VM 8250\VM 8250-000001.vmdk may be inconsistent.
Jun 10 10:54:28.612: vmx| ----------------------------------------
Jun 10 10:54:28.659: vmx| User requested abort: Exiting because of failed disk operation.
Ist doch eine eindeutige Sache.

Für dich vielleicht
Heißt das, die VM 8250-000001.vmdk ist definitiv hinüber und damit auch die VM 8250.vmdk?
Mounten ließ sie sich ja immerhin (wie beschrieben, erst gemountet, später eure Warnung dazu gelesen).

monolithicSparse ist so mit das ungeschickteste, was man in der Virtualisierung machen kann. Zumindest wenn es performant sein und bleiben soll. Wenn deine VMs nicht regelmäßig geschrinkt werden, verweigert irgendwann die WS und kann die VMs nicht mehr starten.

Hab ich nun gestern hier auch erstmals gelesen und war mir vorher keiner Schuld bewusst.
Ja, wie gesagt ein Produkt des Converters, dessen zweifelhafte Qualität ich damals auch erst nach dem Abziehen erfahren hatte. Spricht offensichtlich sowieso nicht für eine einigermaßen zukunftssichere Maschine, sondern eher für den Papierkorb.

Gib es eigentlich einen trifftigen Grund, weshalb du als VM-Speicherort ausgerechnet die als chronisch unzuverlässig bekannten VMware-SharedFolder, also Laufwerk M:\ bei dir, ausgewählt hast

Nein.
Leider die alte Leier: Erst die tollen Shared Folder aktiviert, dann gemerkt, dass die gar nicht richtig funktionieren, hier im Forum nachgelesen und -gefragt, dann die Teile wieder deaktiviert. Im vmx ist mir gestern auch aufgefallen, dass sie dadurch gar nicht richtig verschwinden.
Sollte man am besten die Einträge aus dem vmx ganz löschen oder habe ich das gar im GUI falsch eingestellt?
Die defekte VM liegt ja auf V: des Hosts. Der Host hat aber auch ein M:, dort liegt momentan der Clon, genau. Ich muss jetzt raten, was du mit dieser Frage wirklich meinst. Wären die Shared Folder aktiviert, würde man auf die Dateien der VM aus der VM selbst zugreifen können? Ja, das wäre Käse - vielleicht schlimmer, als überhaupt Shared Folders zu benutzen.
Ich bin aber eigentlich schon Shared Folder-geheilt, siehe oben.

War das jetzt von dir aus eine Anamnese oder schon ein Totenschein?

[Dayworker]

monolithicSparse ist so mit das ungeschickteste, was man in der Virtualisierung machen kann. Zumindest wenn es performant sein und bleiben soll. Wenn deine VMs nicht regelmäßig geschrinkt werden, verweigert irgendwann die WS und kann die VMs nicht mehr starten.

Hab ich nun gestern hier auch erstmals gelesen und war mir vorher keiner Schuld bewusst.
Ja, wie gesagt ein Produkt des Converters, dessen zweifelhafte Qualität ich damals auch erst nach dem Abziehen erfahren hatte. Spricht offensichtlich sowieso nicht für eine einigermaßen zukunftssichere Maschine, sondern eher für den Papierkorb.

Weshalb zweifelhafte Qualität? Sicher nicht wegen "monolithicSparse", daß hättest du selbst in den Converter-Einstellungen verändern können.
In 90% meiner Converter-Läufe ging bisher auch alles meistens glatt. Ausnahmen waren immer multiple OS-Partitionen auf dem Datenträger oder NTFS-Laufwerke mit aktiven Special-Features (ADS, Sparse Files, File compression, EFS, Junctions, Symbolic links) oder für den Converter zu neue Betriebssysteme, aber selbst mit dem Umweg über einem Image-Programm und Restore in eine VM ging das auch nicht immer problemlos durch.

Für die meisten Virtualisierungsfälle gilt auch immer der Grundsatz, daß man den potentiellen Gast einfach in der VM-Umgebung seiner Wahl neu aufsetzen sollte. Dadurch umgeht man alle Probleme, die mit Überbleibseln alter HW-Treiber entstehen, das Gast-OS ist wieder schön schlank und man kann die Anzahl der v.CPUs auf einen für die Virtualisierung besser geeigneten Wert heruntersetzen.

Bei der definitiven Antwort zum Totenschein bin ich überfragt, meine Hoffnung würde da immer auf eine Antwort von Ulli aka continuum ruhen. Wenn er es nicht hinbekommt, brauchst du es über VMware meist auch nicht mehr zu probieren. Das "meist" versteht sich in diesem Zusammenhang auch nur als Fehlermeldung an VMware über einen Fehler in ihrem Produkt. Was in deinem Fall trotzdem sinnlos wäre, da du noch die Jun 10 21:56:25.968: vmx| Log for VMware Workstation pid=3864 version=6.0.0 build=build-45731 option=Release einsetzt und für die 6er Reihe am 08.04.2010 als bisher letzte Version die 6.5.4 veröffentlicht wurde.

[Dreas]

Weshalb zweifelhafte Qualität? Sicher nicht wegen "monolithicSparse", daß hättest du selbst in den Converter-Einstellungen verändern können.

Ok, mangels Knowhow kann ich keine sichere allgemeine Aussage über den Converter treffen und glaube dir gern. Allerdings bestimme ich die Qualität einer Software auch nach ihren Standardeinstellungen. Wenn die in diesem Fall so abwegig sind, dass man hinterher gefragt wird, warum man so einen Blödsinn verzapft, liegt hier immerhin ein Häschen im Pfeffer. Das können andere Firmen wie Microsoft auch prima, deshalb möchte ich auch gar keinen Glaubenskrieg anfangen.
Erst wenn man aus genügend Fehlern schlau geworden ist und vorwiegend graue Haare hat, offenbart so manche Software ihr gewaltiges Potenzial

Für die meisten Virtualisierungsfälle gilt auch immer der Grundsatz, daß man den potentiellen Gast einfach in der VM-Umgebung seiner Wahl neu aufsetzen sollte.

Sehe ich ein, ist logisch und offensichtlich erstrebenswert.
Das unschuldige, aber entscheidende Wörtchen oben kann die erforderliche Arbeit allerdings von einigen Stunden für einen 0815-Arbeitsplatz auf mehr als eine Woche für eine Graue-Haare-Sammlung steigern. Immerhin geht die Software-Reise in diesem Fall ja danach noch deutlich weiter, auch wenn die VM als Umgebung stabil läuft und fertig ist...
Aber im Grundsatz stimme ich dir voll zu und werde das auch umsetzen. Am besten mit einigen möglichst einfach gestrickten Maschinen, nicht einer komplexen.

Vielen Dank erstmal!

[Dayworker]

Am besten mit einigen möglichst einfach gestrickten Maschinen, nicht einer komplexen.

Ist ja dank Virtualisierung kein Problem mehr und gleichzeitig umschifft man damit etwaige Abhängigkeiten bzw Unverträglichkeiten verschiedenster SW untereinander. Obwohl das bei den neueren OS und der üblichen Standard-SW wie Office & Browser eigentlich kaum noch vorkommt. Das kann auf einem Server-OS mit entsprechender Rollenverteilung natürlich schon ganz anders aussehen.

[Dreas]

Leider haben wir hier nicht genug Daten zu deiner VM vorliegen - zip mal die aktuelle vmx - alle kleinen vmdks und eine Dateiliste zusammen und lad das bei ifile.it hoch - dann sehe ich mal nach

Hättest du noch eine Idee?

[Dreas]

Leider haben wir hier nicht genug Daten zu deiner VM vorliegen - zip mal die aktuelle vmx - alle kleinen vmdks und eine Dateiliste zusammen und lad das bei ifile.it hoch - dann sehe ich mal nach

Ulli,
darf ich nochmal anklopfen oder ist deiner Ansicht nach alles gesagt?

[Dayworker]

Wahrscheinlich nicht. Sein neuer Job wird wohl nur mehr Zeit beanspruchen, als er dachte.