VM starten nur als lokaler Admin ?!?!?!?

[Pilgram]

Guten morgen
Wir haben folgendes Problem mit dem starten von Vm auf unserem GSX Server 3.0!
Laut Doku von VmWare kann man VMs Administrieren wenn man lese ,schreib und Ausführen rechte auf das jeweilige vmx file der VM besitzt! Dies klappt allerdings vorne und hinten nicht, selbst mit Vollzugriff gesetzen rechten! Es ist bisher nur möglich VMs zu starten wenn man in der lokaler Admin gruppe ist!
Ist dieses ein bekanntes problem? Geht das überhaupt ohne lokale Admin zu sein(laut doku JA ?!?!)?. Ein benutzer soll die VMs Administrieren aber halt kein lokaler Admin sein! Beim versuch die VM zu starten tut sich erstmal garnix und nach ca 2-3 min kommt dann ein fenster mit "unknown error"! Eine bereits laufende VM kann hingegen voll genutzt und geändert werden auch! Auch ein neue VM zu erstellen ist möglich, aber anschließendes starten der VM geht auch net! Andere berechtigungs stufen funktionieren übrigens!


*greetz* & thx

[Dusty]

Hi Zusammen!

Man kann bei GSX Server 3.0 die VMs privatisieren, d. h. lediglich das lokale Benutzerkonto hat Rechte, die VMs zu administrieren.
Es ist dann auch egal, wie viele Rechte du dem User auf das *.vmx-file gibst.

Schau mal unter VM-Settings-Options-Permissions und nimm den Haken unter Make this virtual machine private heraus.

Das müsste schon reichen!!!


Gruß


Dennis

[Pilgram]

Hy
Ne sorry kann daran nicht liegen da die VMs nicht auf private gesetzt sind! Die Einstellung hat aber soweit ich weis nix mit lokalen benutzer zu tun! Bedeutet doch nur das ausschließlich, der die privat Option aktiviert hat die VM benutzen kann!

trotzdem thx & greetz

[MYO]

Ein LeidensBruder!!!! Endlich!!!

Wir haben das Problem jetzt auch entdeckt.
User, die nicht Mitglied der lokalen Administratorengruppe sind, können zwar die maschine bedienen, wenn sie oben ist, aber die Power On / Off Funktionen kommen mit der Fehlermeldung :
Virtual machine failed to start.

Im Handbuch habe ich das nun so verstanden, dass ich die user der lokalen admingruppe zuweisen muss, und anschliessend die Rechte auf den maschinen "klaue" die sie nicht sehen sollen.
Was soll der scheiss?????

[MYO]

addon:

schaut mal nach im ereignisprotokoll ob der vmauthd gegen die wand kachelt. bin noch auf der suche woran das liegt.
oder vielleicht weiss das schon jemand? (uli?)

[Robert.Schuster]

Es ist gar nicht so schwer, nur finden muss man des Rätsels Lösung...

Ich hatte das gleiche Problem (GSX 3.0, Linux Host) und auch immer den Server bzw. die Rechte-Einstellungen auf den der virtuellen Maschine zugeordneten Files - leider alles Fehlanzeige!

Also:
Es liegt an der Rechtesituation auf der (Verwaltungs-)Workstation. sämtliche beteiligte Files und Registrysettings müssen für die gewünschte User-Gruppe zugänglich sein. Habe noch nicht ausgetestet, welchen Rechte wirklich nötig sind, deshalb empfehle ich hier "Vollzugriff".
Im Filesystem ist das der Programmpfad zur Console, standardmäßig "C:\Programme\VMware\VMware Remote Console\" mit sämtlichen Dateien und Unterverzeichnissen.
In der Registry handelt es sich um 1.) "HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Remote Console" wieder mit allen Einträgen und Unterschlüsseln sowie um 2.) "HKEY_CURRENT_USER\Software\VMware, Inc." auch hier mit allen Einträgen und Unterschlüsseln (jeweils für den aktuell angemeldeten User)
Sollte es zu Problemen bei der Rechtevergabe kommen, so muss zuerst mit "Besitz übernehmen" die Ausgangssituation geschaffen werden.

Meine Erfahrung ist, wer in den erwähnten File- und Registry-Bereichen Vollzugriff hat, kann VMware-sessions beliebig verwalten - vorausgesetzt, seine Server-seitigen Rechte lassen es zu.

Wem das zu kompliziert ist, der kann a) die Console deinstallieren und verbleibende Files manuell löschen und b) die Registry aufräumen (siehe oben). Aber wichtig: Auch beim Löschen müssen ggf. vorher die Rechte angepasst werden.


Gruß
Robert Schuster

[MYO]

Tja also an der Registry alleine scheints nicht zu liegen. bekomme immer noch die einträge im ereignisprotokoll von vmauthd und den Fehler "failed to start"

[continuum]

Hi MYO
ich habe mal so ein bisschen nachgeforscht - wenn petr schon sagt, er wuesste keinen Workaround dann sieht es schlecht aus.

File an incident und schlagt Rabatz bei VMware - damit die merken was los ist.

Ulli

[MYO]

haben wir schon am laufen.

mittlerweile haben wir herausgefunden, dass wenn ein benutzer sich lokal anmeldet, er die maschinen starten und herunterfahren kann. aber über die remotekonsole gehts nicht. komisch wa? :wink:
scheint so als ob der vmauthd dienst nur lokal wirkt.

hab auch schon mit einem lokalen testuser herumgespielt. der funktioniert aber auch nicht über die remote konsole.

*Nachtrag*
Also: User doe nicht der Gruppe der lok. Admins angehören, können die remotekonsole nur dann zum starten benutzen, wenn am server der lokale Admin sich angemeldet hat.

Ulkig oder?

Gruß
MYO

[sweep]

Das Problem ließ sich bei uns auch anders Lösen:

In den Virtual Machine Settings -> Reiter Options -> Startup/Shutdown
Virtual Machine Account auf Local system account setzen.

Wenn virtulle Machinen so eingestellt sind wird die Machine als lokaler Administrator gestartet und nicht als irgendwelche user accounts.
Die Berechtigungen auf Fileebene gelten naturlich weiter.

Viel Erfolg

[HartmutSchaumburg]

Hallo,

es lohnt sich, in der VMware Community nachzuschauen.
Da steht folgendes:

In case anyone else is interested, this problem has been forwarded up with VMWare support, and has been confirmed to be a bug (Bug #45744).

My problem was GSX Server 3.0 running on Windows 2003 Server Standard edition. The problem can be seen when attempting to connect to the server from another machine using the VMWare console, using an account that is not a member of the local administrators group on the host server, and when nobody is logged on to the host server. If an administrator is logged on to the host win2k3 server, the problem will not appear. Same if it is an administrator that logs on through the console - no error.
The error message that does appear is: "Virtual machine failed to start"



Man kann das alles aber wie folgt umgehen und trotzdem Sicherheit gewährleisten:
Den GSX-Host bitte so einstellen, dass er alle virtuellen Maschinen zu einem bestimmten Termin automatisch startet und natürlich stoppt. In den erstellten virtuellen Maschinen wird ein lokaler User angelegt, der Admin dieser virtuellen Maschine ist. Dieser User wird ebenfalls auf dem GSX Host angelegt und auf das Unterverzeichnis dieser virtuellen Maschine berechtigt. Natürlich gehen auch Domänenaccounts. Nutzen mehrere Personen zeitversetzt eine virtuelle Maschine, wird eine Gruppe angelegt und analog vorgegangen.
In der virtuellen Maschine wird ein Remote Client installiert, sofern es NT 4.0 ist. Bei XP ist der RDP-Client von Haus aus dabei.

Der Nutzer bekommt dann mitgeteilt,
auf welche virtuelle Maschine er sich zu verbinden hat,
er kennt keine anderen virtuellen Maschinen,
er kann sich an keiner anderen Maschine anmelden,
er hat nichts mit der VMware-Remote-Konsole zu tun.

Dies stellt sicher,
dass sich die Nutzer nicht selbst mehr Plattenplatz oder RAM zuweisen können und somit den GSX-Host runterziehen,
dass die Administration und das Backup der virtuellen Maschinen zentral gesteuert ist,
dass Missbrauch von virtuellen Maschinen ausgeschlossen ist,
keine Änderungen an Konsoleneinstellungen vorgenommen werden können,


Hartmut Schaumburg

[HartmutSchaumburg]

Hallo,

ich habe das Problem auf einem GSX 3.1Beta_ReleaseCandidate Build_8456 nachgestellt. Auch dort ist der Bug vorhanden.
Es kann gut sein, dass dies an der VMware Remote Console liegt, (der GSX 3.1 Beta_ReleaseCandidate Build_8456 wird derzeit ohne VMware Console und noch ohne Unterstützung für VirtualCenter bereitgestellt und getestet).
Meine Vermutung ist, dass die VMware RemoteConsole von der Produktionsversion des GSX 3.0 mit dem Build 8456 vom GS 3.1 nicht zurechtkommt.

Ich habe daher einen Support-Call bei VMware aufgemacht.
Über das Ergebnis werde ich informieren.

Hartmut Schaumburg

[wuelser]

Hallo

Gibt oder gab es für dieses Problem eine Lösung? Ich kämpfe auch gerade damit.

Danke fürs Feedback

[firefighter]

Warte auf GSX3.2 oder nimm den RC. Ist ein bestätigter Bug.

[sladaloose]

Ich hab den Startup auch auf "Local System" stehen, damit kann man gut leben.

[wuelser]

Danke für die Info, dann kann ich ja aufhören mit meiner Testerei . Dann lass ich einen Admin an der Konsole eingeloggt, das ist für mich die bessere Variante und warte auf die offizielle 3.2.

Gibt es irgendwo ein offiziellen Artikel von VMWare der dies bestätigt, damit man das Kunden beweisen kann? Danke für den Link im Voraus

[firefighter]

Danke für die Info, dann kann ich ja aufhören mit meiner Testerei . Dann lass ich einen Admin an der Konsole eingeloggt, das ist für mich die bessere Variante und warte auf die offizielle 3.2.

Gibt es irgendwo ein offiziellen Artikel von VMWare der dies bestätigt, damit man das Kunden beweisen kann? Danke für den Link im Voraus

http://www.vmware.com/community/thread. ... 7919#27919

has been confirmed to be a bug (Bug #45744).

http://www.vmware.com/community/thread. ... 587#172587

We believe that this is fixed in the GSX 3.2 beta.