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

/var/lib/vco/tools/configuration-cli/bin/vro-configure.sh reset-authentication

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.

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…

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…

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…

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”.

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….

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 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…

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

Für Windows 2008 R2 ist eine ganze Menge Handarbeit nötig: schubis_anleitung_winrm_mit_w2k8r2.pdf

Bei Windows 2012 und PowerShell 3 geht dies wesentlich einfacher mit Enable-PSRemoting. 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.

Nach dem Beenden des Kommandos wird der SDDL String ausgegeben:

Diesen SDDL String kann man wiederum dazu nehmen, die Berechtigung auf verschiedenen Server Auszurollen:

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….)

krb5.conf

[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

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.

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

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

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….

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.

1. Download und Deploy der Appliance
2. Netzwerk konfigurieren
3. als root/vmware anmelden
4. Datei /opt/vmware/share/vami/vami_set_hostname editieren
5. unter http://vcoip/ “Orchestrator Configuration” das Defaultpasswort ändern (für Nutzer vmware)
6. auf der Console die Netzwerkeinstellungen überprüfen und korrigieren (bei mir hat er den Hostnamen als erster DNS Server eingetragen )
7. alle Plugins installieren, die man im Source vCO hatte
8. Konfiguration im Source vCO exportieren
9. Orchestrator Configuration mit vmware / password starten
10. Konfiguration im Target vCO importieren
11. unter Network die IP Adresse der vCO Appliance auswählen und speichern
12. ggf. noch den vCenter FQDN bei “Lizenzen” eintragen, wenn dort “localhost” verwendet wurde

Ich hatte einen simplen Task in einen Workflow mit zu gießen. Dieser bestand aus folgenden Workflows:

1. Generieren von Dummy XML Dateien und Weitergabe des Dateiinhaltes als String
2. XML Content des Strings mit J4X bearbeiten und bestimmte Inhalte von Elementen als OUT Parameter weitergeben
3. 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:

<dummyxml>
  <foo_elem>foo</foo_elem>
  <bar_elem></bar_elem>
</dummyxml>

So kann man diese mittels J4X so generieren (ein Weg von vielen):

var xmldoc = new XML();
xmldoc = <dummyxml></dummyxml>;
 
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:
<dummyxml>
  <foo_elem>foo</foo_elem>
  <bar_elem/>
</dummyxml>

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:

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?

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/