GSX 3.0 Invalid directory . for saved state file.

[doc-sneider]

Hi,

ich habe seit ein paar Wochen das Problem das ich folgende Meldung bekomme wenn ich eine VM suspenden will:

Invalid directory . for saved state file.
Failed to suspend the virtual machine.

Das ganze verwundert mich schon etwas, da die Work-Verzeichnisse alle auf den entsprechenden Konfig-Verzeichnissen der einzelnen VM stehen. Das mit dem Punkt sieht so aus als ob die Verzeichnisse nicht richtig übernommen würden, allerdings sind die auch im config-file der VM eingetragen.

Hatte das einer von euch schon mal?

[continuum]

Hi
schick doch mal ein log von so einem suspend Versuch.

Vorher auf debug stellen - starten - dann suspend versuchen - 10sekunden nach dem Versuch das log kopieren - nicht erst runterfahren oder noch lange laufen lassen.

Continuum

[doc-sneider]

Moin,

soweit ich weis gibt es bei GSX3.0 kein Debug mehr, ich bin mir aber nicht sicher. Deshalb hier der Auszug aus dem "normalen" Log eines beliebingen Servers.

Jun 29 06:51:40: vcpu-0| [msg.checkpoint.baddir] Invalid directory . for saved state file.
Jun 29 06:51:40: vcpu-0| [msg.checkpoint.initiateSuspendFailed] Failed to suspend the virtual machine.
Jun 29 06:51:40: vcpu-0| ----------------------------------------
Jun 29 06:51:40: vcpu-0| POST(no connection): Invalid directory . for saved state file.
Jun 29 06:51:40: vcpu-0| Failed to suspend the virtual machine.

Eine Änderung des Verzeichnisses "." in den Konfig-Files, bringt keine Änderung des Fehlers (Wobei das mit dem ":" schon seltsam ist.

[techElefant]

Ich hatte das gleiche Problem auf einer VM-Ware Workstation 4.5. Leider lässt sich kein Artikel dazu finden, Abhilfe kann jedoch geschaffen werden, sobald das Directory auf irgendeinen beliebigen anderen Pfad verlegt wird.
Ich habe jeweils ein Subdirectory namens "TempFiles" oder ähnlich errichtet und das Working Directory dahinein gestellt, damit funktionieren Suspend und Snapshot wieder.

Der Fehler scheint dann aufzutreten, wenn eine "Basis-" Installation gemoved wird und in einem anderen Directory liegt als bei der ursprünglichen Installation.

[continuum]

Hi
wenn das Problem auftrittt wenn VMs kopiert werden, dann schau mal in den Descriptorfiles der Disks nach, ob da die Pfadangaben noch stimmen.
Bei disks ohne Descriptorfile musst du einen Hexeditor nehmen und bei Offset 200h nachschauen - da findest du den Descriptor der Disk.

Ulli

[techElefant]

Ist das .vmx das Descriptor File? Welches File müsste ich mit dem Hex Editor anschauen?

[continuum]

Hi
die vmx-Datei ist sozusagen eine Beschreibungsdatei der kompletten Hardware - entspricht dem Bestellschein bei einem Echtrechner.

Die Beschreibungsdateien der Festplatten heissen *.vmdk.

Es gibt 6 Festplattentypen bei VMware:

1 raw-disk-: fullDevice
2 raw-disk-: partitionedDevice
3 pre-allocated-: monolithicFlat
4 pre-allocated-:twoGbMaxExtentFlat
5 wachsen bei Bedarf-: monolithicSparse
6 wachsen bei Bedarf-: twoGbMaxExtentSparse

Für alle ausser Typ 5 gibt es eine ca 1KB grosse Beschreibungsdatei die mit einem Texteditor editiert werden kann.
Für den Typ 5 braucht man einen Hexeditor und muss evtl. eine 20GB grosse Datei laden deren Länge man beim Speichern nicht verändern darf - oberste Vorsicht ist angesagt.

Die zugehörigen REDO-logs verhalten sich ähnlich.

Das ist ziemlich pfiffig geregelt.
Die bootende VM - der Gast hat es pro Festplatte mit einer Datei zu tun.
In dieser steht das Kleingedruckte ...

Beispiele : http://sanbarrow.com/vmx-disks4.html

Ulli

[doc-sneider]

Hi,

cool , zumindest kenne ich die Ursache jetzt schon mal. Wir haben tatsächlich die VMs von LW Buchstaben nach Mountpoints umgestellt und da wir den Suspent Mode nur selten benutzen, ist es nicht gleich aufgefallen das der nicht mehr geht.