vMA, VIX, CLI oder ähnliche Fremdsprachen

Hallo Freunde der Sonne,

etwas stressig und manchmal kompliziert anzuwenden sind die Perl-Skripte/Tools von VMware zur Steuerung der Virtuellen Infrastruktur. Dennoch kann einem ein kurzer Blick in die Hilfe der Tools meist verraten – der vClient etc. wird diese wahrscheinlich als Fundament verwenden.

Großartig – starten wir mit dem benennen der einzelnen Abteilungen die man durchlaufen kann:

vMA – vSphere Management Assistant = Linux-VM mit den
CLI – Command Line Interface = Kommandozeilen-Tools zur Steuerung von vSphere

Was gibt es noch:

VIX API – VIX API = ein API für die Steuerung von VMware Produkten
(leider hab ich keinen Namen für VIX gefunden, es handelt sich aber allgemein um:
Virtual Infrastructure X – X steht für übergreifend)

Was ist der Unterschied zwischen CLI und VIX?

Nun ja, nach dem ersten Blick würde man sagen:
CLI ist bei allen Management-Werkzeugen von vSphere eingebaut/vorinstalliert und gibt einem mit vielen Skripten/Programmen die Möglichkeiten alle VMware-Einstellungen vorzunehmen.

Zum Beispiel: Allgemeine Verwaltung Server, Management dieser, Konfiguration dieser, derer Komponenten oder weiter tiefer gehend.

Im Gegensatz hierzu stellt VIX ein Framework/API bereit welches auf möglichst allen Plattformen läuft, eben oben genannte Funktionen zusammenführt und auf der Verpackung des ganzen steht: VMware Workstation; VMware Server; VMware Player.

Stellt sich mir die Frage: Was ist denn nun besser oder ehr für die Verwaltung herangezogen werden?
Übliche Antwort: Kommt darauf an…

1. Plattform
CLI – ist standardmäßig in der vMA eingearbeitet (auf dem vCenter bzw. Client wird meist der vClient vorgezogen)

VIX – kann für Windows/Linux heruntergeladen werden (wobei ich gelesen habe das VIX unter Windows PowerShell-Integration mitbringt – vielleicht wegen SystemCenter?!)

2. Unterstützte Plattformen
CLI – ist primär für vSphere (ESX/ESXi) vorgesehen, ich hatte bisher keinen VMware Server zum Test

VIX – ist für VMware Server, VMware Player, VMware Workstation vorgesehen – kann aber auch ESX/ESXi abfragen

3. Einfache Funktionen
CLI – starten, herunterfahren, einfrieren, Snapshots, Konfigurieren etc. – ebenso Server
– hier ist mir nach ewigem Suchen die Idee gekommen:

vmware-cmd -l

VIX – starten, herunterfahren, einfrieren, Snapshots, Konfigurieren etc. – ebenso Server
– hier habe ich einen Befehl aus der Community gefunden:

vmrun -T viserver -h https://<IP/DNS>/sdk -u „root“ -p „<Password>“ listRegisteredVM

Was denkt man sich natürlich als erstes wenn man eine Liste der registrierten VMs sieht?
Genial fahre ich doch mal eine herunter:

vmrun -T viserver -h https://<IP/DNS>/sdk -u „root“ -p „<Password>“ stop „[datastore1] winxp/winxp.vmx“ soft

Und was war der Output – VM kann nicht heruntergefahren werden, da diese nicht eingeschaltet ist…falsch sie läuft…man kann nicht alles haben.

Nun für alle die ihr Rechenzentrum/Cluster oder einfach vCenter kennen fällt einem der Syntax zur Spezifizierung der VMs auf?!

„[datastore1] winxp/winxp.vmx“

Genau, hiermit lässt sich in Kurzform per vmware-cmd eine Steuerung der VM vornehmen.

Mag jetzt komisch klingen – aber bisher hatte ich per CLI die VMs immer durch den VMX-Pfad gesteuert und war fertig wenn ich bei einem ESX diesen erst noch finden musste…

Gleiches Kommando per CLI:

vifp addserver <Server>

vifptarget -s <Server>

[<Server>]# vmware-cmd „[datastore1] winxp/winxp.vmx“ getstate

getstate() = on

[<Server>]# vmware-cmd „[datastore1] winxp/winxp.vmx“ stop soft

stop() = 1

Genau hier erschließt sich auch jedem anderen wieso CLI angenehmer zu handhaben ist, zum einen weil ich keine Logindaten in das Kommando einbaue (diese werden im Falle abgefragt oder per Fastpath bearbeitet – daher hab ich das [<Server>] vor dem Kommando stehen gelassen) und zum anderen weil die CLI auf der vMA einen höheren Zweck erfüllt als nur Kommandos des Administrators zu übertragen.

Was könnten denn Aufgaben einer vMA sein?

Die Verwaltung von ESX/ESXi-Servern,

dass Auslesen des Status und der Logfiles als zentrale Sammelstelle und

als Zugriffs-/Integrationsmodul für Drittherstellersoftware – wie den PCNS-Agent.

(dieser kann dank der vMA alle registrierten Server herunterfahren ohne auf den ESXi-Servern installiert werden zu können)

Nun ja, dieser Artikel beschäftigt sich mit äußerst gefährlichem Halbwissen,

dennoch halte ich es für Sinnvoll sich diese Themen einmal im Hinterkopf zu behalten oder weiter zu erlernen.

Alleine die Fähigkeit Steuerungs-Agents die auf dem erweiterungsfeindlichen ESXi 5.0 keine Chance hätten über die vMA per CLI die Server steuern zu lassen ist doch ein Lichtblick.

(wird übrigens von VMware als Standardvorgehen angemerkt)

Bis dann erstmal.