ESX / ESXi - Hilfethread

[Cluster_]

Klasse!
Das Script beendet den Aufwand bei ESXi free + ZFS Snaps da es viel einfacher zu handhaben ist als ssh +esxcli und als Basis für allerlei Automatisierungen dienen kann.

Darf das Script frei genutzt werden.
Ich würde das auch gerne anderen AiO/ZFS Nutzern bekanntmachen.

Machen, machen.

Hat mir spaß gemacht.
Für den dritten Tag Perl coden bin ich recht zufrieden. War ein netter Einstieg

Gruß
Thomas

 

[gea]

Das mit dem dritten Tag nehme ich mit einem Schmunzeln zur Kenntnis...

Perl ist für System Management nach wie vor ideal.
Für Perl gibts übrigens einen klasse Editor kostenlos, http://www.dzsoft.com/register.htm?app=dzperl

ps
Kann man bei list_snapshot auch die description mit ausgeben?
Würde für die snap commands nicht die vm_id alleine genügen?

 

[Cluster_]

Das mit dem dritten Tag nehme ich mit einem Schmunzeln zur Kenntnis...

Perl ist für System Management nach wie vor ideal.
Für Perl gibts übrigens einen klasse Editor kostenlos, http://www.dzsoft.com/register.htm?app=dzperl

ps
Kann man bei list_snapshot auch die description mit ausgeben?
Würde für die snap commands nicht die vm_id alleine genügen?

Leider nein. Die Snapshot commands sind recht wissenshungrig
Bei list_snapshot geben ich nur den aktuellen snapshot aus. Ich erhalte aber so ziemlich den ganzen Pfad inkl. etwaiiger Randdaten. Also ja, könnte man hinbekommen.

Beitrag automatisch zusammengeführt: 19.02.2023

Hab aber gerade noch einen Bug gefunden

Nachdem @gea jetzt das Script in seinem Napp-It verknüpft hat, werde ich das File in die dementsprechenden Thread-ID verschieben und dort upgedated halten und bei Bedarf nur auf diesen Eintrag verlinken:

VMware_SOAP

Gruß
Thomas

 

[gea]

ok, aktualisiert

napp-it ZFS server on OmniOS/Solaris: news, tips and tricks

File and share permissions, new option in current napp-it dev You can use SAMBA on Solarish operating systems but mostly you prefer the Solaris integrated multithreaded kernelbased SMB server due easier setup, perfect integration of Windows ntfs alike permissions with inheritance, Windows SID...

forums.servethehome.com

 

[Cluster_]

ok, aktualisiert

napp-it ZFS server on OmniOS/Solaris: news, tips and tricks

File and share permissions, new option in current napp-it dev You can use SAMBA on Solarish operating systems but mostly you prefer the Solaris integrated multithreaded kernelbased SMB server due easier setup, perfect integration of Windows ntfs alike permissions with inheritance, Windows SID...

forums.servethehome.com

Ich werde die Datei in diesem Post upgedated halten wenn ich noch etwas finde / ändere.

Vor allem Deine Frage von Gestern bzgl. den SnapShot Descriptions ist hängen geblieben. Evtl führe ich noch eine summary Option ein alla
Host
|-Datastore1 (mounthost: x | mountpoint: y | MOID: z)
| |-VM ID: 1 (Name: xyz)
| |- Current Snapshot ID: 1-snap-x (Name: xyz | Description: xyz | Date: yyyy-mm-dd)
| |- Snapshot parent 1.....
.....


Done - Ver 1.01

VMware_SOAP_ver1.01


Gruß
Thomas

 

[Cluster_]

ok, aktualisiert

napp-it ZFS server on OmniOS/Solaris: news, tips and tricks

File and share permissions, new option in current napp-it dev You can use SAMBA on Solarish operating systems but mostly you prefer the Solaris integrated multithreaded kernelbased SMB server due easier setup, perfect integration of Windows ntfs alike permissions with inheritance, Windows SID...

forums.servethehome.com

@gea Die summary action sollte das was Du wolltest recht gut abbilden oder?

Und sorry für das Umstellen von mounthost/mountpoint auf moid - Aber das ergibt einfach mehr Sinn weil man hier auch die internen datastores ansprechen kann.

example: list VMs:
perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/soap/VMware_SOAP.pl list_attached_vms --host 192.168.2.48 --user root --password 1234 --mountpoint /nvme/nfs --mounthost 192.168.2.203

-->
perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/soap/VMware_SOAP.pl list_attached_vms --host 192.168.2.48 --user root --password 1234 --moid 192.168.2.203:/nvme/nfs
oder eben auch
perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/soap/VMware_SOAP.pl list_attached_vms --host 192.168.2.48 --user root --password 1234 --moid 63757dea-d2c65df0-3249-0025905dea0a

Im example: create snap
Die Parameter mem und quiesce sind default mit --mem (=true) und --no-quiesce (=false) belegt.
--mem yes --quiesce yes funktioniert hier mit den bool-werten nicht - Die Wahl ist --mem oder --no-mem (oder --nomem)


Gruß
Thomas

 

[gea]

Danke, passt prima,

ich baue gerade ein napp-it menü um das Script komfortabel zu testen.
Eine komfortable SOAP Schnittstelle ist etwas was wirklich gefehlt hat.

 

[mrpasc]

Ich als Homelabber sage einfach mal fettes Danke an @Cluster_ und @gea

 

[gea]

Ich habe mal ein Menü in napp-it gebaut (neueste 23.dev) um die aktuellen Optionen zu testen.
Die SOAP Schnittstelle ist genial für Automatisierungen in ESXi.

@Cluster_ (Thomas)
Je mehr ich mit dem Script rumspiele, desto mehr bin ich begeistert.
Dein Script ist sowas wie ein Schweizer Taschenmesser für Automatisierungen in ESXi

 

[Cluster_]

@Cluster_ (Thomas)
Je mehr ich mit dem Script rumspiele, desto mehr bin ich begeistert.
Dein Script ist sowas wie ein Schweizer Taschenmesser für Automatisierungen in ESXi

Hallo, DAS freut mich sehr. Vor allem, nachdem ich das Grundgerüst nur zum Not-Shutdown an der APC erstellt hatte mit einem einzigen call

Ich hab es auch so gehalten, dass zusätzliche actions rel. einfach eingepflegt werden können. Bleibt nur zu Hoffen, dass das so "offen" bleibt. Aber nachdem sie offiziell auf die API und das SDK verweisen denke ich schon.
Die Summary ist das einzige was in dem Script aufgrund der der nötigen foreach'es aus dem Rahmen fällt.

Generell kannst Du mit der API und über die direkten SOAP calls alles erledigen vom single-host bis zum HA-Cluster.
Der VM mob (managed object browser) viewer des Servers ist hier sehr Hilfreich um die Syntax zu sehen und auch zumindest bei Read-Aufgaben zu prüfen.

Und dann im Browser über

https://192.168.1.1/mob/?moid=ha-datastoresystem

z.B. direkt das datastoresystem zu sehen
(z.B. ha-host / ha-datastoresystem / ha-servicemanager / ha-property-collector / etc...)

Deine Implementierung sieht aber auch sehr schön aus. Das einzige das mir direkt auffällt sind die fehlenden XML-Like Definitions (z.B. <VM> etc) und die Farbcodes die nicht Dargestellt werden für Status-DS und State-VM (heartbeat)

Und wenn es was helfen sollte unter Linux für die Ausgabe der Erklärung für jede action:

for i in $(./VMware_SOAP.pl | grep -A100 "Implemented actions:" | sed 1,2d); do ./VMware_SOAP.pl $i;done


Gruß
Thomas

 

[gea]

Deine Implementierung sieht aber auch sehr schön aus. Das einzige das mir direkt auffällt sind die fehlenden XML-Like Definitions (z.B. <VM> etc) und die Farbcodes die nicht Dargestellt werden für Status-DS und State-VM (heartbeat)

Ich gebe die Daten über einen Webserver an den Browser. Damit werden tags wie <VM>nicht dargestellt und Console Farbkommandos müsste man in <font color> übersetzen. Läßt sich aber machen indem ich z.B. die spitze Klammer durch html entitities ersetze.

ps
ok, siiehe https://www.hardwareluxx.de/community/threads/esx-esxi-hilfethread.748644/page-291#post-29760606

 

[Cluster_]

Ich gebe die Daten über einen Webserver an den Browser. Damit werden tags wie <VM>nicht dargestellt und Console Farbkommandos müsste man in <font color> übersetzen. Läßt sich aber machen indem ich z.B. die spitze Klammer durch html entitities ersetze.

ps
ok, siiehe https://www.hardwareluxx.de/community/threads/esx-esxi-hilfethread.748644/page-291#post-29760606

Es sieht irgendwie aufgeräumter aus so

Btw, noch ein zusätzliches Script welches mit Chrome im Inkognito modus jeweils im manager_entries.xml enthaltene Links öffnet.
Ich habe meinen Source vbs und das kompilierte exe eingefügt. Das xml muss im selben Verzeichnis liegen.
Bei recht vielen verschiedenen Adressen kann das recht hilfreich sein.

Außerdem: Da der Hauptteil von dem Script einfach darin besteht entries zu parsen und dann an die shell weiterzuleiten, gibt es in Verbindung mit dem Windows Linux Subsystem auch die Möglichkeit verschiedene commands auf "Anwendungsebene" an z.B. das VMware_SOAP script weiterzuleiten. Nur so als denkanstoß.

Ich habe in dem script jetzt noch zwei item-types eingefügt - Damit ergibt sich
target = Start chrome inkognito mit adresse
action = Start command mit normalen Nutzerrechten
elevatedaction = Start command mit Adminrechten (Erstellt ein cmd file im temp dir -> Startet dieses mit Adminrechten und löscht es danach wieder

Ein paar Beispiele sind im manager_entries.xml file vorhanden (z.B. VLAN wechsel, oder VMware_SOAP calls.

Gruß
Thomas

 

[gea]

Es sieht irgendwie aufgeräumter aus so

Außerdem: Da der Hauptteil von dem Script einfach darin besteht entries zu parsen und dann an die shell weiterzuleiten, gibt es in Verbindung mit dem Windows Linux Subsystem auch die Möglichkeit verschiedene commands auf "Anwendungsebene" an z.B. das VMWare_SOAP script weiterzuleiten. Nur so als denkanstoß.

Gruß
Thomas

Danke, schau ich mir noch an, nutze aber Windows eher für Desktop Sachen als für Server Management.
Der Vorteil von deinem Perl Soap Script ist, dass damit ultra einfach kleine Automatisierungsscripte erstellt werden können. Das Schöne daran, das funktioniert. mit Perl Scripten sogar plattformunabhängig per cronjob oder geplantem Task. Das Einzige was noch fehlt ist Basis VM Management, z.B. VM status, poweroff, poweron, shutdown und reset.

 

[Mac_leod]

Guten Morgen,
wenn eine LUN (hängt per iscsi an einer DELL EMC Unity) einfach auf Storage Seite gelöscht wurde ohne die vorher unzumounten und alle ESXer jetzt rumheulen wo die LUN hin ist, hab ich eine Chance per CLI auf vcsa Ebene die loszuwerden oder muss ich alle Hosts einzeln abgrasen und die rauskratzen?
Ist zu lange her, kann mich nicht erinnern.
Der Azubi hat dann andere Aufgaben bekommen

 

[Cluster_]

Danke, schau ich mir noch an, nutze aber Windows eher für Desktop Sachen als für Server Management.
Der Vorteil von deinem Perl Soap Script ist, dass damit ultra einfach kleine Automatisierungsscripte erstellt werden können. Das Schöne daran, das funktioniert. mit Perl Scripten sogar plattformunabhängig per cronjob oder geplantem Task. Das Einzige was noch fehlt ist Basis VM Management, z.B. VM status, poweroff, poweron, shutdown und reset.

Version 1.02 ist raus

Der Status der vm kommt ja in der Summary.
Du kannst ja auch mit einem grep pipe die Ausgabe im Nachhinein begrenzen
z.B.
./VMware_SOAP.pl summary --host 192.168.1.1 --user root --password 1234567890 | grep \<VM\>
./VMware_SOAP.pl summary --host 192.168.1.1 --user root --password 1234567890 | grep \<DataStore\>

Ich habe jetzt noch kleine Hilftexte zu den actions geschrieben
shutdown funktioniert jetzt nur noch unter Angabe von --scope (host/vm/guest)
neue actions die im scope laufen können (poweron / shutdown / reboot / kill)
create snapshot hat nun den ISO konformen date time als fixen prefix - Dadurch ist snapname und snapdesc jetzt optional

VMware_SOAP_ver1.02

Gruß
Thomas

 

[Cluster_]

+ Update ServerManager
Jetzt mit run command Userlevel + Adminlevel

Beitrag automatisch zusammengeführt: 21.02.2023

Guten Morgen,
wenn eine LUN (hängt per iscsi an einer DELL EMC Unity) einfach auf Storage Seite gelöscht wurde ohne die vorher unzumounten und alle ESXer jetzt rumheulen wo die LUN hin ist, hab ich eine Chance per CLI auf vcsa Ebene die loszuwerden oder muss ich alle Hosts einzeln abgrasen und die rauskratzen?
Ist zu lange her, kann mich nicht erinnern.
Der Azubi hat dann andere Aufgaben bekommen

Hi

siehe (wenn das passt )
https://www.provirtualzone.com/vmwa...etach-iscsi-volumes-manually-in-a-esxi-shell/

 

[gea]

Version 1.02 ist raus

Ich habe jetzt noch kleine Hilftexte zu den actions geschrieben
shutdown funktioniert jetzt nur noch unter Angabe von --scope (host/vm/guest)
neue actions die im scope laufen können (poweron / shutdown / reboot / kill)
create snapshot hat nun den ISO konformen date time als fixen prefix - Dadurch ist snapname und snapdesc jetzt optional

VMWare_SOAP_ver1.02

Gruß
Thomas

Danke, habe das in mein Menü System > ESXi integriert

 

[Cluster_]

Danke, habe das in mein Menü System > ESXi integriert

Eine Kleinigkeit die ich noch geändert habe, ist der Name des scripts -> VMWare_SOAP.pl --> VMware_SOAP.pl
Ich habe gesehen, dass ich den Namen nicht richtig geschrieben hatte und Du schon.

Haarspalterei, aber trotzdem

Gruß
Thomas

 

[gea]

kleine Anmerkung.
Abschließene Meldung sollte successfully (mit ss) lauten, falls man return values auswertet

 

[Cluster_]

kleine Anmerkung.
Abschließene Meldung sollte successfully (mit ss) lauten, falls man return values auswertet

Hallo - Danke
Stillschweigend in 1.02 nachgezogen

 

[gea]

Nur am Rande (ich filtere es raus und kann damit leben)

Wenn man das Tool in Scripten zur Automatisierung nutzt, stören die Console Farbkommandos etwas bei der Auswertung.
Besser wäre es wenn man das wegläßt oder einschaltbar macht so wie beim debug/verbose modus oder eventuell wie auch vor der abschließenden Meldung ein result: setzt.

 

[Cluster_]

Nur am Rande (ich filtere es raus und kann damit leben)

Wenn man das Tool in Scripten zur Automatisierung nutzt, stören die Console Farbkommandos etwas bei der Auswertung.
Besser wäre es wenn man das wegläßt oder einschaltbar macht so wie beim debug/verbose modus oder eventuell wie auch vor der abschließenden Meldung ein result: setzt.

Ich hab mal versucht das colorcoding vorweg zu nehemn. Evtl. ist das besser/leichter

VMware_SOAP_ver1.03

Gruß
Thomas

 

[gea]

Im Prinzip geht es darum, dass für Automatisierungsanwendungen das aufrufende Script eine Auswertung vornimmt. Gibt das Script auch auf Konsole aus, werden die Farben korrekt dargestellt, Erfolgt die Ausgabe auf html (Webserver) muss die Farbdarstellung immer per html Befehl erfolgen. Konsole Farben müssen dann ersetzt werden. Mit State: green ohne Konsole Farben ist das aber in der Tat einfacher da man ab State: das Ergebnis auswertet.

Ich beabsichtige folgende Darstellung (richte mich dabei an die Vorgaben des Scripts):

So einfach, komfortabel und komplett habe ich meine ESXi noch nie dargestellt bekommen!
Das Integrieren von ESXi Snaps in ZFS Snaps damit man daraus ein konstistentes Backup/Recovery machen kann, habe ich bisher oft gelassen weil relativ aufwändig. Ist jetzt ein Klacks.

 

[Cluster_]

Freut mich sehr. - Mal was nützliches gemacht

Allerdings, (und ich weiß nicht wieso - evtl kann mir das einer Erklären) bleibt der NFS status auf grün - Gefühlt immer. Ich habe mal eine VM erstellt - shutdown - und dann den NFS datastore entfernt (die Freigabe serverseitig beendet). Den ESXi hat das irgendwie nicht beeindruckt . Ich konnte zwar nicht mehr über den Datastorebrowser auf den Storage zugreifen, der Status allerdings blieb grün.
Das dürfte doch eigentlich nicht sein.

Gruß & Dank
Thomas

 

[gea]

Zum Thema NFS kann ich leider nichts beitragen. Ich würde erwarten dass ESXi erst bei einem nicht erfolgreichen Zugriff einen Fehler feststellt.

Zu 1.03
Die farbigen Rechtecke machen viel mehr Probleme bei der Verarbeitung in Scripten als Console Farben wie [32m. Die kann man leicht rausfiltern. Spezielle Zeichen(sätze) machen Probleme bei der Verarbeitung. Scripte mögen am liebsten ASCII. Ideal wäre etwas wie --nocolor als Option um keine Farben auszugeben.

Ein einfaches State: green oder Status: green wäre gut. Das könnte man bei Bedarf bei der Ausgabe genau wie ein Wort 'green' aus einem Scrupt problemlos farbig darstellen

 

[Cluster_]

Die farbigen Rechtecke machen viel mehr Probleme bei der Verarbeitung in Scripten als Console Farben wie [32m. Die kann man leicht rausfiltern. Spezielle Zeichen(sätze) machen Probleme bei der Verarbeitung. Scripte mögen am liebsten ASCII. Ideal wäre etwas wie --nocolor als Option um keine Farben auszugeben.

Hallo ich habe jetzt einen "plain" modifier eingebaut um die Farben generell abzuschalten. (Sprich einfach --plain anhängen).
Das betrifft alles farbige (also auch die Success / Fail messages).
Außerdem habe ich im debug modus manche Dinge noch farbig dargestellt (wenn nicht plain ). Hilft optisch dem Faden zu folgen.

VMware_SOAP_ver1.04

Gruß
Thomas

 

[gea]

Perfekt für den interaktiven Scriptmodus.

Ich habe es bereits eingepflegt und stelle die Farben per html font color dar. Jetzt muss ich mal schauen wie ich das am Besten mit ZFS autosnaps verknüpfe und vor allem zeitliche Abläufe koordiniere. Wenn ich z.B. ein ESXi snap remove bei remove all snaps anfordere während ein vorheriges remove noch läuft, so schlägt es fehl (es wird bereits eine andere Aufgabe ausgeführt). Da muss ich noch eine Wartezeit einplanen oder den "busy" Status einer VM abfragen

 

[Cluster_]

Perfekt für den interaktiven Scriptmodus.

Ich habe es bereits eingepflegt und stelle die Farben per html font color dar. Jetzt muss ich mal schauen wie ich das am Besten mit ZFS autosnaps verknüpfe und vor allem zeitliche Abläufe koordiniere. Wenn ich z.B. ein ESXi snap remove bei remove all snaps anfordere während ein vorheriges remove noch läuft, so schlägt es fehl (es wird bereits eine andere Aufgabe ausgeführt). Da muss ich noch eine Wartezeit einplanen oder den "busy" Status einer VM abfragen

Schwierig. Der removeSnapshot liefert als Antwort eine objectID zu eben diesem Task. Das Problem ist nur - Wohin damit. Nach der Laufzeit meines Scripts ist diese Info weg und da das ein dynamische Objekt ist würde es eine Monitor-Schleife erfordern die mein Script solange am leben hält, solange dieser Task auf dem Host besteht. In Verbindung mit der Webimplementierung kann ich mir vorstellen, dass das etwas Problematisch ist bzgl. Time-Outs.

Dein Problem sollte allerdings nur Tasks betreffen, die auf die selbe VM zugreifen , richtig?
Alternativ könnte ich dir noch ein removeAllSnapshots anbieten.

Nebenbei - Die removeSnapshot methoden können auch verhindern, dass die Disks konsolidiert werden. Der Standard ist konsolidieren. Ich habe diesen Parameter nicht mit implementiert. Soll ich das noch machen?
Laut VMware ist das dafür gedacht, fehlerhafte Snapshots zu löschen. "... You can also use the Delete option to remove a corrupt snapshot and its files from an abandoned branch of the snapshot tree without merging them with the parent snapshot...."

Gruß
Thomas

 

[gea]

Das Problem ist mir bei einem remove all Snapshots aufgefallen Da lese ich über summary alle Snaps ein und lösche die per snap_remove. Eventuell könnte das Problem auch auftauchen wenn man einen Snap anlegen möchte während ein remove noch läuft. Das Script selber wird dann per Snap remove neu in einer Schleife im Menüscript gestartet. Das ist zeitlich unkritisch. Auch könnte sich ein auftrufendes Programm um die ObjectID kümmern. Ein länger laufendes Script das sich selber um remove all snaps einer VM kümmert wäre auch toll. Da man slbst einzelne ESXi Snäps nie länger als wenige Tage bestehen lassen sollte, ist ein remove all sehr sinnvoll um aufzuräumen vor allem in Kombination mit ZFS weil da will man ja bei Bedarf hunderte ZFS Snaps jeweils mit dem dann aktuellen Stand eingebettet als ESXi Snap.

Lediglich wenn ein Script interaktiv in der webui länger läuft als ein cgi timeout des Webservers oder Browsers müsste ich mir überlegen die Verarbeitung in einen eigenen Hintergrund Task zu verlegen. Dann wäre die Laufzeit unkritisch und das aufrufende Programm würde einfach warten bis alles abgearbeitet ist bzw ein Fehler geliefert wird. Bei einer Jobverarbeitung z.B. in einem Autosnap + cron Job läuft das Script eh solange wie nötig im Hintergrund.

Gibt es eine Möglichkeit einen busy state einer VM abzufragen um etwas in der Art
while (vmbusy) { wait, timeout max n sek } zu implementieren.

Oder ist der vm=yellow state dafür geeignet?
Ein wiederholtes Aufrufen von summary wird aber wohl auch Last bedeuten. Denkbar wäre auch dass dein Script erst nach erfolgreichen Aktionen endet und dann Erfolg, Misserfolg oder Timeout meldet. Laufzeit mit einem einstellbaren Timeout von vielleicht 1 bzw 10min wäre unkritisch. Das wäre vielleicht das beste Verhalten.

Insgesamt sollten Standardaufgaben im Script möglich sein, Sonderfälle wohl besser in der ESXi webconsole gelöst werden. Das per Script zu automatisieren geht zusehr Richtung KI. Schön ware halt dass man dafür sorgen kann dass ein Snap create bzw remove tatsächlich stattfindet und nicht wegen einem VM busy dann zwar angenommen aber nicht ausgeführt wird.

ps
Vermisst sonst jemand der auch ESXi All in One oder ESXi + VMs auf NFS ganz allgemein nutzt noch eine Aktion?

 

[Cluster_]

Gibt es eine Möglichkeit einen busy state einer VM abzufragen um etwas in der Art
while (vmbusy) { wait, timeout max n sek } zu implementieren.

Ich fürchte nein. Die VM ist rein technisch nicht in die Snapshotaufgaben eingebunden.
Der Status der VM bleibt daher gleich. Nur auf dem ESXi Host selber läuft eben ein Task. Und diesen kann ich nur Abfragen wenn ich die Object ID dazu habe.

Oder allgemein
Welcher Task läuft gerade -> welche ID hat dieser-> Hole mir die Infos zu dieser Task ID -> Welches ManagedObject hat diesen Task ausgelöst -> Ist diese Objekt in die aktuelle angefragte action involviert -> Wenn ja dann warte bis dieser Task vorbei ist.

Und danach kommen ja evtl. noch wartende Tasks im Host die ich dann parallel (aber nacheinander der Taskliste folgend) nach obigen Schema abfragen müsste und ggf. obig berücksichtigen müsste.

Eine Möglichkeit wie "Find attached tasks to VM" habe ich in den Methoden beim überfliegen nicht gefunden.

Ich fürchte leider, dass das ein nicht allzu triviales Problem ist.

Gruß
Thomas