mehrere VMs als Administrator starten

[as]

Hi all,

ich hab drei VMs (WinXP, Win2003Server und SuSE Linux Enterprise Server) unter einem Host (VMWare Server auf Win2003 Server) laufen. Die config-files liegen lokal, die vmdk-files auf einem Fileserver. Alle drei VMs sollen als 'Administrator' laufen.
Jede VM startet unter den beschriebenen Angaben einzeln einwandfrei, soweit eben nur eine VM gestartet wird. Beim Versuch bei einer bereits laufenden VM eine zweite zu starten, kommt folgende Fehlermeldung:

Cannot open the disk '\\Enas\vmware\VM03_Win2003Server\VM03_Win2003Server.vmdk' or one of the snapshot disks it depends on.
Reason: Failed to lock the file.

Hat da jemand eine Idee?

[al!ve]

Öhm ... ja.

Hattest du vor Jahrmillionen mal eine VM erstellt und um das VMX-File nicht neu erstellen zu müssen dieses einfach zwei Mal kopiert für die zwei nachfolgenden VMs? Die Fehlermeldung sagt aus, dass die VM die du starten willst ein File für eine virtuelle HDD einbinden will, die anderweitig gesperrt ist.

Vorzustellen:
VM erstellt.
Vmdk-File (virtuelle HDD) dafür angelegt, Snapshot erzeugt. Dadurch bleibt die "Ursprungsdatei" unverändert, alle Änderungen am virtuellen Dateisystem kommen in eine extra Date.
VM kopiert. Die kopierte "extra Datei" bezieht sich jedoch auf das alte vmdk-File.

[as]

Sorry, ich hab alle drei VMs regulaer und jeweils neu erstellt. Auch hab ich noch nie einen Snapshot erzeugt.

[as]

Ich habs also nochmal versucht. Wenn alle drei VMs lokal auf dem VM Server gespeichert sind, funktionieren sie einwandfrei, lassen sich auch mit lokalem Systemkonto bzw. als Administrator starten. Das Problem existiert nur, wenn ich die vmdk-files auf einen Fileserver auslagere, obwohl dort Vollzugriff auf die Verzeichnisse und Dateien besteht.

[I.P.]

zu deiner frage habe ich konkret auch keine idee weil vmware grundsätzlich vmdk files von beliebigen quellen (also auch vom fileserver) akzeptiert aber warum willst du das machen? sind dir die vms zu schnell? oder zu stabil?

ich würde das problem beim zugriff auf den fileserver vermuten. was ist das für ein ding? gibts vielleicht eine session-beschränkung in bezug auf gleichzeitig geöffnete files oder etwas in der art?

[as]

Vielen Dank für Deine Antwort,
zu Deiner Frage des 'Warum?': Ich möchte die vmdks auf meinen Fileserver auslagern, da dieser zum einen wesentlich mehr Speichekapazität hat und zum anderen die Daten dort regelmässig über dieses System gebackuped und gesnapshoted werden.
Zum Server selbst: es ist ein Open-E NAS-XSR ENTERPRISE Server. Ich hab dort ein separates Share eingerichtet. Offensichtlich liegt es an dieser Verbindung, da die VMs lokal ja einwandfrei laufen. Von Session-Beschränkungen weiss ich nichts. Ich werd jedenfalls mal an dieser Stelle weiterforschen.
Leider fand ich bisher nur wenig hilfreiche Beschreibungen bzgl. der Speicherung von VMs auf externen Servern bzw. Netzlaufwerken. Offensichtlich geht man davon aus, dass diese immer auf dem lokalen System gespeichert werden.?

[stefan.becker]

Idee habe ich auch keine, aber macht das überhaupt Sinn?

Das muss doch eine Performancebremse hoch sieben sein.

[continuum]

Das muss doch eine Performancebremse hoch sieben sein.

Wieso denn das ?

Schon bei meiner billig Hardware kann ich mit VMs die auf einem Fileserver liegen ganz gut arbeiten - gigabit network mal vorraus gesetzt

[stefan.becker]

gigabit network mal vorraus gesetzt

Dann mag das gehen. Dennoch ist doch die lokale Platte besser.

[rprengel]

Ich habs also nochmal versucht. Wenn alle drei VMs lokal auf dem VM Server gespeichert sind, funktionieren sie einwandfrei, lassen sich auch mit lokalem Systemkonto bzw. als Administrator starten. Das Problem existiert nur, wenn ich die vmdk-files auf einen Fileserver auslagere, obwohl dort Vollzugriff auf die Verzeichnisse und Dateien besteht.

Schau was in den Logfiles steht
unter Linux /tmp under Windows keine Ahnung wo
Ich hatte den Effekt mal

Unter /tmp sollten sich Logfiles mit ersten Hinweisen finden.
Mögliche Ursachen:


aus meiner eigene FAQ
o Rechte auf Verzeichnisse/ Dateien sind falsch
o DNS fehlerhaft, VMware versucht einen Namesauflösung des Clients wenn z.B. eine Maschine über ein Netzwerklaufwerk gestartet wird.
o Dateien schon vorhanden und gesperrt und/ oder in einem unklaren Zustand.
o unter /var/run/vmware prüfen ob der aktuelle user und seine Ids noch stimmig sind. Ggf. einfach löschen.