====== Orchestrator ======
====== nützliche Tools & CMDs für 8.x ======
kubectl get pods --all-namespaces
root@vco8 [ ~ ]# kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
ingress ingress-ctl-traefik-74b69f8544-g75gm 1/1 Running 4 56d
kube-system coredns-2s46g 1/1 Running 4 56d
kube-system endpoints-weight-6s6z9 1/1 Running 4 56d
kube-system etcd-itsz-vco8.htwk-leipzig.de 1/1 Running 4 56d
kube-system health-reporting-app-67hpd 1/1 Running 4 56d
kube-system kube-apiserver-itsz-vco8.htwk-leipzig.de 1/1 Running 6 56d
kube-system kube-controller-manager-itsz-vco8.htwk-leipzig.de 1/1 Running 14 56d
kube-system kube-flannel-ds-8hdps 2/2 Running 23 56d
kube-system kube-proxy-mjj2f 1/1 Running 4 56d
kube-system kube-scheduler-itsz-vco8.htwk-leipzig.de 1/1 Running 14 56d
kube-system kubelet-rubber-stamp-p2qxx 1/1 Running 4 56d
kube-system metrics-server-gqcsh 1/1 Running 4 56d
kube-system predictable-pod-scheduler-jln7r 1/1 Running 4 56d
kube-system prelude-noop-extnet-ds-d7n5n 1/1 Running 4 56d
kube-system prelude-noop-intnet-ds-2cfqf 2/2 Running 8 56d
kube-system state-enforcement-cron-1617263640-2qrxv 0/1 Error 0 2m25s
kube-system state-enforcement-cron-1617263640-cbtcr 0/1 Error 0 115s
kube-system state-enforcement-cron-1617263640-hkqk8 0/1 Error 0 2m15s
kube-system state-enforcement-cron-1617263640-ql7b2 0/1 Error 0 75s
kube-system state-enforcement-cron-1617263640-vw4dp 0/1 Error 0 2m28s
kube-system tiller-deploy-89fdbcb48-bp5ck 1/1 Running 9 56d
prelude orchestration-ui-app-6744d98cd5-j59n8 1/1 Running 4 56d
prelude pgpool-8698f9f994-r2zmx 1/1 Running 14 56d
prelude postgres-0 1/1 Running 4 56d
prelude proxy-service-5c78496786-blczs 1/1 Running 4 56d
prelude symphony-logging-7fc8cdbd95-9bz4z 1/1 Running 4 56d
prelude vco-app-6ff995b4bf-vvt88 3/3 Running 4 47h
===== VRO Authentifizierung zurücksetzen =====
/var/lib/vco/tools/configuration-cli/bin/vro-configure.sh reset-authentication
===== vCO/vRO Appliance mehr Java Heap =====
Die Appliance ist etwas "mager" mit Java Heap ausgestattet.
Darum:
* ''/usr/lib/vco/app-server/bin/setenv.sh'' editieren
* Zeile beginnend mit ''MEM_OPTS'' auf ''MEM_OPTS="-Xmx6144m -XX:MaxPermSize=256m -Xss256k -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/var/core/"'' ändern
* Neustart
Bei mir hat die Appliance 4 CPUs und 8GB RAM bekommen.
===== vCO/vRO Workflows in der WebGUI ohne vorbelegte Parameter =====
WFs in der WebGUI sind mit den Parametern des Objektes vorbelegt, bei dem der WF als Kontext Action gestartet wurde.
Meistens jedenfalls :-)
Sollte dies nicht der Fall sein, liegt es an einer "fehlerhaften Registrierung" des vCenters im Orchestrator.
Die Registrierung (der String) muss **exakt** gleich wie in der WebGUI sein. D.h. incl. Groß/Kleinschreibung.
Darum erst in die WebGUI gehen, vCenter Instanz auswählen und schauen, wie die Registrierung aussieht und genau so verwenden.
Das vCenter kann ja auch mittels IP registriert sein...
===== VCO / VRO als WebGUI Extension registrieren =====
Es kommt immer wieder die Frage, was man im WF ''Register ... extension'' als ''External address ...'' angibt.
Hier reicht nicht die IP oder FQDN der VCO Instanz aus, sondern incl. https und Port, wie im Screenshot...
{{:vmware:vco_extension.png?500|}}
//Dabei ist wichtig, sowohl die vCenter Plugin Konfiguration, wie auch die oben stehende Extension Registrierung mit **FQDN** und __nicht mit IP__ vorzunehmen. Ansonsten werden bei WFs, die über die WebGUI aufgerufen werden die Parameter nicht vorbelegt...//
===== Keine vCenter/AD etc. Workflows in Libraries Pfad vorhanden =====
Wenn eine vRO 6.x Appliance ausgerollt wird, kann es vorkommen, dass nach der vollständigen Konfiguration des Orchestrators unterhalb des Library Pfades keine Workflows bzw. nur sehr wenige vorhanden sind.
Trotz installierten vCenter- oder AD Plugin sind z.B. dafür keinerlei Workflows da.
Das Problem wird meist durch die Umkonfiguration der vRO Datenbank hervorgerufen (PostgreSQL -> SQLServer).
Die Lösung ist simpel. In der Konfigurationsoberfläche gibt es den Punkt "Troubleshooting".
{{:vmware:vro_troubleshooting.png?600|}}
In diese Oberfläche wechseln und dort "Reset current version" auswählen. Danach die Appliance neu starten. Dadurch werden beim Neustart alle Plugins neu installiert und sieh da - alle Workflows sind wieder da....
===== ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY bei vCO/vRO Aufruf =====
Die meisten Brwoser haben inzwischen auf Schwachstellen in der SSL/TSL Verschlüsselung reagiert und unsichere Schlüsselgruppen verbannt. Dazu zählt auch der Diffie-Hellman Schlüsselaustausch mit zu kurzer Länge, der vor allem auch die [[https://weakdh.org/|Logjam Attacke]] ermöglichte.
Das führt dazu, dass aktuell bei Aufruf der vCO Konfigurations- oder Übersichtsseite der Fehler "''ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY''" angezeigt wird und die entsprechende Seite nicht geladen werden kann.
Es gibt zwei Lösungsmöglichkeiten:
* Den Brwoser dazu zu bringen, diese Schlüssel doch zu akzeptieren (gibt's mehr als genug Anleitungen dafür), das halte ich aber für sehr problematisch
* Den Orchestrator dazu bringen, diese unsicheren Schlüssel nicht mehr zu nehmen.
Der zweite Weg ist recht einfach. Für den App-Server muss in der Konfig-Datei ''server.xml'' nur nach ''ciphers'' gesucht werden. Bei der vCO/vRO Appliance liegt die Datei unter ''/etc/vco/app-server'' und bei einer Windows Installation sollte diese unterhalb von ''...\app-server\conf'' liegen. Da die Konfigurationsseite mit einem separatem Server ausgeliefert wird, muss ebenfalls ''/var/lib/vco/configuration/conf/server.xml'' editiert werden.
Originalinhalt:
... scheme="https" secure="true" sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" strategy="ms"
ciphers="TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC
_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA"/>
Ändern in
... scheme="https" secure="true" sslEnabledProtocols="TLSv1, TLSv1.1, TLSv1.2" strategy="ms"
ciphers="TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA"/>
Das war alles...
===== vCO - externe SQLServer Datenbank =====
Wenn vCO in größeren Umgebungen verwendet wird, soll eine externe DB genutzt werden.
Ich bevorzuge SQLServer.
Die entsprechende DB soll dann auf ''ALLOW_SNAPSHOT_ISOLATION'' und ''READ_COMMITTED_SNAPSHOT'' gesetzt werden.
Der einfachste Weg:
ALTER DATABASE TEST
SET READ_COMMITTED_SNAPSHOT ON
WITH ROLLBACK IMMEDIATE;
GO
ALTER DATABASE TEST
SET ALLOW_SNAPSHOT_ISOLATION ON;
GO
===== WinRM für PowerShell Plugin einrichten =====
Für Windows 2008 R2 ist eine ganze Menge Handarbeit nötig:
{{:vmware:schubis_anleitung_winrm_mit_w2k8r2.pdf|}}
Bei Windows 2012 und PowerShell 3 geht dies wesentlich einfacher mit ''Enable-PSRemoting''.
[[https://technet.microsoft.com/en-us/library/hh849694.aspx|siehe Technet Artikel]]
Das Enable-PSRemoting aktiviert den WinRM Dienst und und - das ist so ziemlich das wichtigste - setzt die ACLs via SDDL.
Möchte man nun einem Nutzer Rechte geben, nutzt man der Einfach halber lieber ''winrm configSDDL default''.
{{:vmware:ps-remoting-winrm.png?375|}}
Nach dem Beenden des Kommandos wird der SDDL String ausgegeben:
{{:vmware:sddl_example.png?640|}}
Diesen SDDL String kann man wiederum dazu nehmen, die Berechtigung auf verschiedenen Server Auszurollen:
{{:vmware:set_sddl.png?650|}}
Ggf. muss Orchestrator noch als Trusted Host hinzugefügt werden.
Set-Item wsman:\localhost\Client\TrustedHosts vco-server -Concatenate -Force
Wenn man dann noch aus dem vCO Basic Authentication verwenden möchte, muss man dies auf dem Zielsystem noch einschalten.
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}
winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/client @{AllowUnencrypted="true"}
Es wäre zu schön. wenn dies reichen würde. Auch in den GPOs muss Basic Auth eingeschaltet werden.
gpedit.msc -> Computer Configuration -> Administrative Templates -> Windows Components -> Windows Remote Management (WinRM)
Bei Client und Server die Basic Authentication einschalten.
Danach sehen die winrm config Abfragen auch etwas anders aus:
C:\Windows\system32>winrm get winrm/config/service/auth
Auth
Basic = true [Source="GPO"]
Kerberos = true
Negotiate = true
Certificate = false
CredSSP = false
CbtHardeningLevel = Relaxed
C:\Windows\system32>winrm get winrm/config/client/auth
Auth
Basic = true [Source="GPO"]
Digest = true
Kerberos = true
Negotiate = true
Certificate = true
CredSSP = false
Danach muss, wie im Win2K8R2 Dokument beschrieben, noch Kerberos konfiguriert werden. Wer die 6er vSphere Appliance einsetzt -> ''/usr/java/jre-vmware/lib/security/'' (steht auch bei der aktuellen Doku von VMware falsch drin....)
[libdefaults]
default_realm = DOMAIN.DE
udp_preference_limit = 1
[realms]
DOMAIN.DE = {
kdc = DC-01.DOMAIN.DE
default_domain = DOMAIN.DE
}
[domain_realm]
.domain.de=DOMAIN.DE
domain.de=DOMAIN.DE
===== Resourcen =====
Meine Infos rund um Orchestrator hole ich vor allem von Jörg Lew, Freund und oft schon rettender Helfer.
Auf seiner Seite www.vcoportal.de gibt es sehr viele und nützliche Infos rund um Orchestrator und dessen Plugins.
Eine weitere Sammlung beherbergt www.vcoteam.info. Dort gibt es ebenfalls eine Menge Beispiele.
Und natürlich die Seiten der VMware Community unter http://communities.vmware.com/community/vmtn/server/vcenter/orchestrator. Dort ist besonders der Artikel und die Beispiele von Christophe Decanini über VCD Blocking Tasks und deren Verarbeitung hilfreich.
===== Anmelden des vCO Clients schlägt mit einer java.jms.JMSException fehl =====
Bei mir ist meist für das Problem die FireWall bei einer Windows vCO Installation dran schuld gewesen.
Meist schalte ich diese einfach aus. In Kundenumgebungen ist dies aber nicht immer möglich.
Schuld an dem Fehler sind die geblockten Ports 8286 und 8287, die so nicht in den vCO Requirements drin stehen...
Übrigens hilft nicht, "Notify me" bei der Firewall einzuschalten, um geschlossene Ports mitzubekommen.
Bei mir gabs nie einen Hinweis aufs Blocken :-(
===== Plugins =====
vCenter Orchestrator kann mit div. Plugins erweitert werden.
Ich habe bisher mit fogenden gearbeitet:
* AD Plugin
* vCD PLugin
* AMQP Plugin
* Perspective Plugin
* Mail Plugin
* SQL Plugin
* vCenter 5 Plugin
* PowerShell Plugin (das von Jörg Lew - http://www.vcoportal.de/powersshell-plugin/)
* HTTP REST Plugin
==== vCloud Director Plugin Konfiguration ====
Falls es Probleme bei der Konfiguration des vCloud Director Plugins gibt, ist meist das Zertifikat schuld ;-)
Nutzt man z.B. Shared Session für die Nutzer und bekommt immer wieder die Meldung, das der Nutzer XY nicht angemeldet werden kann, ist meist das Zertifikat des vCD nicht geladen bzw. nicht mehr gültig.
Einfach kontrollieren, indem man auf Zertifikate geht, dort bei Download from URL die vCD IP oder Hostnamen eintragen, Zertifikat abrufen und speichern.
Das war bisher immer das Problem, wenn die Anmeldung nicht funktionierte....
===== vCO Appliance "vergisst" FQDN =====
Wer das Problem hat, dass die vCO Appliance nach einem Reboot den falschen Hostnamen hat, sollte
die Datei ''/opt/vmware/share/vami/vami_set_hostname'' wie in KB Article 2012535 beschrieben, editieren.
===== Migration Windows vCO auf vCO Appliance =====
- Download und Deploy der Appliance
- Netzwerk konfigurieren
- als root/vmware anmelden
- Datei ''/opt/vmware/share/vami/vami_set_hostname'' editieren
- unter ''http://vcoip/'' "Orchestrator Configuration" das Defaultpasswort ändern (für Nutzer vmware)
- auf der Console die Netzwerkeinstellungen überprüfen und korrigieren (bei mir hat er den Hostnamen als erster DNS Server eingetragen :-( )
- alle Plugins installieren, die man im Source vCO hatte
- Konfiguration im Source vCO exportieren
- Orchestrator Configuration mit vmware / password starten
- Konfiguration im Target vCO importieren
- unter Network die IP Adresse der vCO Appliance auswählen und speichern
- ggf. noch den vCenter FQDN bei "Lizenzen" eintragen, wenn dort "localhost" verwendet wurde
===== Stolperfalle bei XML mit J4X einlesen =====
Ich hatte einen simplen Task in einen Workflow mit zu gießen. Dieser bestand aus folgenden Workflows:
- Generieren von Dummy XML Dateien und Weitergabe des Dateiinhaltes als String
- XML Content des Strings mit J4X bearbeiten und bestimmte Inhalte von Elementen als OUT Parameter weitergeben
- die OUT Parameter als IN Parameter für einen SQL Workflow zum Wegschreiben in eine DB nutzen
Alles lief wunderbar bis auf den ersten Test des Workflows :-(
"''Mandatory field not set''" war die Fehlermeldung...
Doch wieso das? Ausufernde Debugmeldungen zeigten, dass alle Parameter gesetzt waren und der Workflow direkt zwischen den Workflows 2 und 3.
Es hat eine ganze Weile gebraucht, bis ich das Problem erkannt hatte. Deshalb der Artikel - es kann jedem passieren :-)
Um die Lösung vorneweg zu nehmen - es lag an der automatischen J4X Konvertierung.
Ich möchte es anhand eines Beispiels zeigen. Folgende XML Datei ist zu bauen:
foo
So kann man diese mittels J4X so generieren (ein Weg von vielen):
var xmldoc = new XML();
xmldoc = ;
xmldoc.foo_elem = "foo";
xmldoc.bar_elem = "";
Dieses XML kann man im Orchestrator ganz einfach anzeigen mittels
System.log("my XML Doc:\n" + xmldoc);
ergibt
2012-03-24 21:44:37.030] [I] my XML Doc:
foo
Nun noch flink den Parameter ausgelesen und zur Sicherheit ausgegeben
var foo = xmldoc.foo_elem;
System.log("Value of foo is '" + foo + "'");
ergibt wie erwartet
[2012-03-24 21:48:48.498] [I] Value of foo is 'foo';
Ist doch alles fein - warum die Aufregung?
Meine Folgeworkflow mag String Parameter und das ist das Problem!
Durch die automatische J4X Konvertierung sehe ich im Log ''String'' aber die Variable ist vom Typ ''XML''.
Mein Test:
var foo = xmldoc.foo_elem;
System.log("Value of foo is '" + foo + "'; Type is " + typeof foo);
ergibt
[2012-03-24 21:54:54.459] [I] Value of foo is 'foo'; Type is xml
Und nicht wie erwartet String. Da ich mit J4X nicht vertraut bin, habe ich verschiedene Möglichkeiten getestet.
Mal in einer Tabelle zusammengefasst:
^ Wertabfrage ^ Wert ^ Result Typ ^
| xmldoc.foo_elem | foo | xml |
| xmldoc.foo_elem.text() | foo | xml |
| xmldoc.foo_elem.data() | foo | xml |
| new String(xmldoc.foo_elem) | foo | object |
| new String(xmldoc.foo_elem.text().toString()) | foo | object |
| new String(xmldoc.foo_elem.toString()) | foo | object |
Erwartet wurde von mir aber ''String''. Auch Workflow 3 erwartet String Parameter.
Da meine XML Dateien sehr einfach aufgebaut sind und auch nicht so groß, habe ich dann mittels DOM meine "String" Werte bekommen...
var document = XMLManager.fromString(xmldoc.toString()).getDocumentElement();
var foo = document.getElementsByTagName("foo_elem").item(0).textContent;
ergibt dann
[2012-03-24 22:35:44.635] [I] Value of foo is 'foo'; Type is string
Damit gehts.
Hat jemand eine bessere Idee?
===== nützliche Links =====
https://www.vcoteam.info/articles/learn-vco/304-postman-vro-http-rest-plug-in-operations.html
https://blogs.vmware.com/management/2019/02/extracting-data-from-vrealize-operations-with-the-rest-apis.html
https://code.vmware.com/samples/4663/postman-client-collection-for-vrealize-operations-rest-apis?h=john%20dias
https://docs.vmware.com/en/vRealize-Operations-Manager/7.0/vrealize-operations-manager-70-api-guide.pdf
http://virtual-red-dot.info/vrealize-operations-6-7-vm-memory-counters/
https://i2.wp.com/desfontaines.eu/wp-content/uploads/2015/11/20151126-vROps_REST_01-S006.png
https://desfontaines.eu/2015/11/27/vrops-how-to-use-the-rest-api-to-gather-a-metrics-configuration-details/