VMware-Forum

Hallo,

Ich hätte da mal 2 Fragen:

Frage1:
Gibt es die Möglichkeit beim VM ESX 2.1.1 die Virtuellen Maschinen
zeitgesteuert zu starten bzw. beenden?

Zur Erklärung:
Um die virtuellen Maschinen (jeweils eigene LUNS im SAN) zu sichern,
möchte ich sie zum Zeitpunkt x herunterfahren, und dann zeitgesteuert wieder starten. Das herunterfahren läßt sich mit den Bordmitteln des Host OS regeln, aber wie kann ich Sie automatisiert wieder starten. (Ohne den ganzen VM Ware Server zu booten)

Frage2:
Welche Rechte bzw. welchen Gruppen muß ein User zugeordnet werden, damit er eine Hostmaschine per VM-Console bedienen darf?

Danke für Eure Hilfe!

Gruß

Torsten

zu 1.)
mit den "vmware-cmd" utilities
oder mit den perl scripts aus "vmware scripting API"
... damit können die Virtuellen Maschinen gestartet gestoppt susspended und noch andere Sachen gemacht werden. Das ganze muss dann nur noch mit "cron" gescheduled werden.

Zum sichern der VM genügt es die VM zu suspend'en.
Es gibt aber auch die Möglichkeit mit REDO logs ein Sicherungskonzept umzusetzen.

zu 2.)
Die Rechte werden für die Files benötigt, welche von der VM benutzt werden (config files und dsk).
r w x anlegen und verändern, starten und stoppen der virtuellen Maschine
r x starten und stoppen der Virtuellen Maschine mit der Remote Console
r Benutzer zum anzeigen/überwachen der virtuellen Maschine
... Gruppen sind zum bedienen mit der Remote Console keine nötig.

Hallo.

Wenn du die VMs sichern willst, das geht auch ohne sie zu beenden.

Grüße
Alex

wandan hat geschrieben:Hallo.

Wenn du die VMs sichern willst, das geht auch ohne sie zu beenden.

Grüße
Alex

dabei ist jedoch folgendes zu bedenken:

1.) kann die eingesetzte Backupsoftware Server komplett sichern (egal ob Virtuel oder Physisch); also auch die Dateien die im Zugriff sind und für einen Recovery Fall wichtig sind (weil das System sonst korrupt wäre). Nicht jede Backupsoftware unterstützt dies. Oft werden für diese Features extra Lizenzen verlangt.

2.) VM können nur dann im laufenden Betrieb gesichert werden wenn man mit *.dsk.REDO Dateien (die sogenannten REDO log's) arbeitet. Dann können die *.dsk Dateien on the fly gesichert werden, weil die Änderungen in die *.dsk.REDO reingeschrieben werden. Dabei ist zu beachten, dass die Änderungen auch in die *.dsk Datei wieder reingeschrieben wird (-> mit dem "commit" Befehl); wenn die Änderungen nicht übernommen wrden hat man im schlimmsten Fall einen alten Stand der VM.

... oder wie schon oben geschrieben die VM auf "suspend" setzen, dann wird die Maschine kurz "eingefroren" und kann gesichert werden.

Hallo,

erstmal mal vielen Dank für die schnelle Hilfe.


Wenn mann eine virtuelle Maschine in den Suspend Modus setzt, ist dann wirklich der Speicher des Gast OS leer und keine Datei vom mehr Gast OS (z.B. W2K3) geöffnet, so daß ich im Disaster-Fall einfach nur ein Backup d.h. Sicherung einer im Suspend Modus befindlichen virtuellen Maschine bzw. der virtuellen HD (in meinem Fall die komplette LUN) zurückhole und alles läuft wieder?


Leider bin Linux technisch eher ein Einsteiger, ich vermute aber, daß die genannten Lösungen bezüglich cron/vm-cmdutils bzw. Rechte über die Console des ESX-Server eingeben werden müssen. Wo finde ich weitere Informationen bzw. Anleitungen, Beispiele zu den Themen?


Gruß

Torsten

wenn die VM im suspend modus ist, dann kann das *.dsk file gesichert werden.
Es wird der aktuelle Zustand gesichert und die VM kann dann an anderer Stelle wieder hochgefahren werden (config files nicht vergessen).
Die VM wird dabei eingefroren und ist in dieser Zeit(während der Sicherung bis die VM wieder gestartet wird) auch nicht erreichbar. Der Speicher wird dabei nicht geleert. Die Maschine fährt an der gleichen Stelle wieder hoch an dem die VM eingefroren wurde. Diese Lösung kann für einen Disaster Recovery Fall genutzt werden.

Nach dem suspend müssen die VM wieder mit vmware-cmd oder scripting-API gestartet werden.

Wie auch schon erwähnt ist es möglich mit den Redo logs ein Sicherungskonzept umzusetzen.
d.h. mal ganz kurz beschrieben ... das *.dsk file in den append oder undoable Modus versetzen, mit addredo und commit die *.dsk aktuallisieren.


Für Informationen zu cron gib einfach
man cron
in der Service console ein.

Mit den Berechtigungen unter Linux freundet man sich eigentlich auch sehr leicht an.
Schau dir folgendes an:
man chmod
man chown
man chgrp

Und das dürfte auch hilfreich sein:
http://www.vmware.com/support/developer ... index.html
http://www.vmware.com/support/esx2/doc/vmware-cmd.html

... um die Service Console kommst du nicht herum. Die tools sind also schon das Handwerkszeug für den ESX Server.

mit dem Script unter http://www.vmts.net/download.htm können die VMs automatisiert gesichert werden

CU

Hallo.

Backup ist immer ein sehr heikles und oftmals diskutiertes Thema. Meiner Meinung nach gibt es hier nicht die für jeden passende Lösung.

Generell kann man auf einem ESX Server folgendes unterscheiden

1. Sicherung über Service Konsole (dsk Files)
2. Sicherung innerhalb der VM (Daten)
3. Sicherung innerhalb der VM (Komplett)

Hier muss man denke ich entscheiden, welche Daten habe ich auf den VM´s und wie oft ändert sich da was. Also wie aktuell brauche ich eine Sicherung. Auch wäre es wichtig mal einen Restore / Recovery durchzugehen. Das wird oftmals nämlich vernachlässigt. Alles wird schön gesichter, aber niemand kann es wieder herstellen.


Zu Punkt1.
Wie cdv schon gesagt hatte, kann man eine suspended Maschine wunderbar sichern. Hierbei braucht man aber mehr Platz, da zusätzlich zum DSK auch noch das Suspend File zu sichern ist. Oder man sichert nur das dsk und verliert die aktuellen Laufzeit Infos.
Per Skript kann man die Maschinen nachts runterfahren und die DSK´s wegkopieren. Ob per skript oder einer unterstützen Backup Software auf der Service Konsole... wie gesagt.. viele Möglichkeiten. Bei manchen muss man bischen skripten.. bei anderen paar Euros zahlen.. oder auf schon lizensierte Software zurückgreifen. Interessant hierbei, in wie weit das ESX Backup mit in die bestehende Infrastruktur zu integrieren ist. Welche Auswertungen , Alarme usw. benötige ich.

Zu Punkt2.
Zum Backup innerhalb der VM kann jede gängige Backupsoftware verwendet werden. Dies ist vollkommen unabhängig vom ESX Server.
Hierbei ist höchstens zu beachten, dass sich eventuell mehrere VM´s die gleichen Netzwerkkarten teilen. Und je nach Backup Volumen kann dann die Backup Zeit entsprechend ansteigen. Hier empfielt es sich, sogenannte Backup Farmen zu definieren. So dass nicht alle Server zur gleichen Zeit anlaufen

Zu Punkt3
Wie cdv auch schon geschrieben hat, ist es für ein komplett Backup (Disaster Backup) notwendig, dass die Software über einen OFM (open File Manager) verfügt (einen funktionierenden) Damit auch im zugriff befindliche Files gesichert werden. Wie auch bei allen anderen Lösungen gibt es hier verschiedene Produkte. Sowohl auf Image Basis wie auch als "normale" Sicherung.

Bei Backup wird in den meisten Umgebungen von einem Backup Konzept gesprochen, und nicht nur vom Einsatz eines Tools. Dies weist auf die Komplexität des Themas hin.

Aber ich merke gerade.. ich weiche vom Topic ab.

Grüße
Alex

Hallo,

mittlerweile kann ich meine VM-Maschinen zeitgesteuert beenden und starten.(mittels cron und vmcmd-utils). DANKE!

Noch mal zum Thema Sicherungskonzept:

Meine Vorstellung
1. Ich fahre alle VM Maschinen zeitgesteuert um 23.45 Uhr herunter.
2. Ich mache auf dem SAN ( NetApp Filer FAS270C) einen Snapshot, der die LUNs in welchen sich ja die HDs der VM Maschinen befinden, sichert.
3. Ich starte alle VM Maschinen zeitgesteuert um 23.55 Uhr.
4. Der Snapshot wird auf Band gesichert.

Die Konfigdatei der VM Host Maschinen liegt zwar auf der lokalen HD des ESX-Server. Kann aber doch jederzeit neu erzeugt werden (Neue Maschine am ESX registrieren gesicherte LUN zuordnen fertig.)oder?


Beim den Rechten kämpfe ich noch!


Gruß und schönes WE

Torsten

PS:vi ist ... sagen wir mal etwas gewöhnungsbedürftig

Hallo.

Ja, die Konfigurationsfiles (VMX) kann man natürlich jedezeit wieder neu erstellen und die DSK´s auf dem SAN einbinden. Interessant wäre es nur, wenn man änderungen am Bios der VM gemacht hat (nvram) oder aber spezielle Konfigurationen vorgenommen hat. Wenn alles standard ist kein Thema. Ansonsten gut dokumentieren oder die VMX Files nach der finalen Konfiguration wegsichern. (Tip: vmware-support)

Was ist denn genau die Frage bei den Berechtigungen?

Vm´s immer mit einem "normalen" User anlegen und konfigurieren.
Root sieht alle VM´s
User sehen nur Vm´s wo sie leserechte auf die VMX Files haben.
Änderungen bedürfen write recht auf dem VMX File.
Remote Konsole braucht zusätzlich execute auf dem VMX File.

Am besten kurz die Anforderung beschreiben, was mit dem Rechte Konzept umgesetzt werden soll. Vielleicht gibt es ja da eine gute Lösung für.

Grüße
Alex

Hallo,

also noch mal zum Thema Rechte:

Ich habe alle VM-Maschinen als root erstellt. Ich möchte aber einigen Kollegen ermöglichen Ihre VM-Maschinen zu beenden und neu zu starten bzw. per Remote Console zu verwalten.

Wenn ich als normaler User eine VM Maschine anlege, habe ich das Problem, daß ich nach Konfigurationsänderungen im SAN (z.B. neue LUN zuordnen) keinen Refresh auf dem FC-Adapter machen kann, um die neue virtuelle Disk zu sehen und einzubinden.

Bei bestehender Konfiguration müßte ich also einen neuen user anlegen und ihm RX Rechte auf die Konfigdatei der betroffenen Maschine geben?

Rechte Beispiel:
Iststand:
-rwxr-xr-- 1 root root esxmaschine.vmx

Wie kann ich jetzt dem Benutzer XY Rechte auf die Datei geben ohne die Rechte von root einzuschränken?


Gruß

Torsten

Hallo.

Generell die VM´s immer mit einem user Account erstellen.
Der Root Account sieht sie immer in der Web gui und hat auch immer Rechte darauf. Root halt. *G

Auch wenn die Vm´s für User angelegt sind, kannst du als root einen refresh das SAN Adapters machen.

Auch per konsole: vmkfstools -s vmhba0 (oder sowas)

chown test:test esxmaschine.vmx
chmod 700 esxmaschine.vmx // eventuell halt noch rechte für ne gruppe bei bedarf

Grüße
Alex

Hallo

ich habe wie vorgeschlagen alle VM-Maschinen noch mal als "normaler user" angelegt.

Jetzt läuf alles wie geschmiert (bzw. "virtualisiert").

Danke nochmals für die Eure Hilfe.


PS:
Eine Frage sei mir hoffentlich noch gestattet. Gibt es die Möglichkeit (CD images) iso Dateien so im SAN abzulegen das mehrere ESX Server(bzw. Ihre Hosts) darauf zugreifen können?



Gruß

Torsten

Hallo.

Generell kannst du natürlich eine LUN für mehrere ESX Server freigeben.
Normalerweise legt man dan auf son einer LUN das VMFS Volume an, und legt dort die DSK Files der virtuellen Platten ab.

Wenn ich mich hier jetzt irre, korrigiert mich bitte. Aber soviel ich weis, kann man auf ein VMFS Volume auch nur auf die DSK Files zugreifen. Die DSK Files müssen auf einem "normalen" Dateisystem sein, welches natürlich einen entsprechenden MountPoint im Dateisystem hat.

Ich lege mir dazu immer ein /isofiles an. Und das kann natürlich auch im SAN liegen.

Grüße
Alex