VMware-Tools für Linux-Server ohne GUI? Auto-Shutdown?

[vm-Dennis]

Hi zusammen!

In einer WS9 habe ich ownCloud (Ubuntu 12.04 LTS) aufgesetzt. Die VM startet via Shared-VM-Autostart mit Start des Hosts, damit sich iPhone und iPad synchronisieren.

Die VM soll wöchentlich auf ein NAS weggeschrieben werden. Dazu verwende ich 'SyncBack Pro'. Um die VM sauber wegzuschreiben, muss sie also sauber heruntergefahren werden.

Soweit die Vorgeschichte.

VMware-Tools habe ich eher als "Grafik-" und "Drag & Drop"-Treiber wahrgenommen. Für alte Versionen fand ich den Hinweis, dass man mit VMware-Tools und Kommandozeile die VM sauber herunterfahren kann. Allerdings schweigt sich die Hilfe zu WS9 dazu aus oder ich suche falsch...

Gibt es das nicht mehr? Wenn ja, wie gehe ich vor?

Merci!

Dennis

[Dayworker]

Die VM kannst du auch so sauber runterfahren entweder per VMware und "vmrun" oder per SSH-Shutdownscript. Das ganze Sicherungsprozedere inklu VM-Restart kannst du auch komplett scripten, solltest dann aber sowohl für den VM-Shutdown bzw -restart als auch den Sync-Durchlauf selbst immer etwas Karenzzeit einplanen.

[vm-Dennis]

Kannst Du mich mal passend schubsen? Die Hilfe schweigt sich aus.

Wenn ich einen "Shutdown" in WS9 mache, sieht es so aus, als zöge er einfach den Stecker. Mache ich auf der Konsole ein "shutdown -h now" fährt er richtig runter.

Mache ich was falsch? Wie würdest Du so einen Befehl absetzen? Gern über die Kommandozeile (Host: Win7) da eben direkt von SyncBack Pro steuerbar.

Ich danke Dir!

[Dayworker]

Die vmrun-Syntax habe ich im Thread Schnellverwaltung des VMserver2 von der CMD oder Ba$h aus beschrieben und sollte auch unter WS9 noch Gültigkeit haben. Notfalls startest du vmrun einfach mal auf der CMD und kopierst die Ausgabe in eine Datei.
Falls der WS9-Shutdown wirklich nur den Stecker zieht, dürfte "plink" dein Freund sein, um ein "shutdown -h now" per SSH von Windows aus abzusetzen.
Dessen Syntax sollte sich aus folgendem Script ergeben:

Code: Alles auswählen

plink.exe -ssh benutzer@aaa.bbb.ccc.ddd -P 22 -pw passwort shutdown -h now

Voraussetzung für den Shutdown ist allerdings, daß der angegebene Benutzer zum Shutdown berechtigt ist. Unter Ubuntu ist dazu meiner Erinnerung nach noch etwas Vorarbeit nötig, die die ubuntuusers.de-Community oder war es das Ubuntu-Wiki beschreibt.

[vm-Dennis]

Super - ich liebe undokumentierte Features. Danke Dir. Wird durchgelesen...

Gedanklich stoße ich derzeit an zwei Hürden, die ich nicht zu lösen weiß.

- Wie kann ich prüfen, ob WS9 nur den Stecker zieht? "Optisch" sieht es so aus. Aber wie kann ich sicher sein?

- plink scheidet aus. Der HOST hat keinen Zugriff auf das betroffene lokale Netzwerk, in dem die VM läuft.

Noch eine andere Frage:
Lohnt es sich bei VMs, bei den Backups zu versionieren? Meine virutelle Platte ist auf mehrere Dateien gesplittet. Ich bekomme die doch nie wieder mit versionierten Dateien zusammengefrickelt, oder?

[Dayworker]

Wieso undokumentierte Features? Die "vmrun"-Syntax habe ich 1:1 vom VMserver2 übernommen und für "plink" brauchst du nur Benutzernamen, Passwort und die IP deiner OwnCloud-VM einsetzen...

Ob VMware einfach den Stecker gezogen hat, siehst du in deinem Linux meist unter /var/log/messages.

Weshalb scheidet "plink" aus? Damit du die WS9 extern beeinflussen kannst, mußt du doch eh einige Ports offen haben und da macht der dafür vorgesehene Port 22 auch nichts mehr aus. Wenn du dir um die Sicherheit Sorgen machst, kannst du den SSH-Port ja auch auf einen anderen Port legen.

Die Frage nach der Versionierung einer vDISK würde ich unabhängig vom vDISK-Typ (Sparse, Preallocated, enbloc oder in 2GB-Häppchen) verneinen, da du je nach Änderung in jedem Fall einen wesentlich grösseren Block sichern müßtest. Nur bei einer Sparse-Disk in 2GB-Häppchen könntest du Glück haben, da die VMDK ja nur die geänderten Sektoren enthält. Allerdings sind Sparse-Disk die langsamsten und benötigen Pflege in Form des Shrinkens, damit zum einen die Luft aus der VMDK gelassen wird und zum anderen die Sparse-Disk auf dem Host-Datenträger wieder in Reihe kommt. Bei einer Preallocated dagegen müßten in jedem Fall eine 2GB-Datei und enbloc sogar die gesamte VMDK gesichert werden. Es würde von der Warte mehr Sinn machen, wenn du den OwnCloud-Bereich einfach per "rsync" in eine weitere, nur für die OwnCloud-Sicherung zu startende Linux-VM replizieren würdest.