SimpliVity Omnicube - Auf welchem Knoten liegt die Maschine?

Sobald man mehr als zwei OmniCube Knoten in einem Cluster hat stellt sich die Frage, auf welchem der Knoten eine virtuelle Maschine physisch liegt. Es gibt immer zwei OmniCubes, auf denen die virtuelle Maschine abgelegt ist.

Welche das sind, findet man über die Kommandozeile eines beliebigen Omnicubes raus:

svt-vm-show --output xml | xmlstarlet sel -T -t -m /CommandResult/VM -s A:T:U "name" -v "concat (platformName,'|',owner,'|',replicaSet)" -n |awk 'BEGIN {FS = "|"} ; {printf "%s\n Owner:  %s\n   Replicas: %s\n",$1,$2,$3; }' | sed `svt-federation-show --output xml |xmlstarlet sel -T -t -m /CommandResult/Node -s A:T:U "hostName" -v "concat ('s/',id,'/',hostName,'/g;')"` | grep -A 2 [VM Name]

Beziehungsweise, wenn von Interesse ist welcher Host welche VM's beinhaltet:

svt-vm-show --output xml | xmlstarlet sel -T -t -m /CommandResult/VM -s A:T:U "name" -v "concat (platformName,'|',owner,'|',replicaSet)" -n |awk 'BEGIN {FS = "|"} ; {printf "%s\n Owner:  %s\n   Replicas: %s\n",$1,$2,$3; }' | sed `svt-federation-show --output xml |xmlstarlet sel -T -t -m /CommandResult/Node -s A:T:U "hostName" -v "concat ('s/',id,'/',hostName,'/g;')"` | grep -B 2 [Hostname]

Horizon View Composer offline Update

Wichtiger KB:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2081888

VMware Horizon View 6 Upgrade - View Manager nicht erreichbar

Es gibt derzeit einen Bug beim Upgrade auf VMware Horizon View 6 in Umgebungen in welchen "vCenter Operations for View" verwendet wird.

In diesen Umgebungen läuft auf den View Connection Servern der Dienst "vCenter Operations for View Broker Agent"

Der Dienst ist vor Beginn des Upgrades zwingend zu beenden, da er Dateien im Zugriff hat die andernfalls nicht aktualisiert werden.

Vergisst man dies, quitiert der View Manager das nach dem Upgrade mit Logeinträgen wie:

2014-03-25T20:06:36.074-04:00 ERROR (0EDC-0C38) [ws_java_bridgeDLL] Java Bridge Managed failed on serviceClass = jniEnv->FindClass(serviceClassName._mstr())

vCenter Operations - Max Number of Supported Resources

vCenter Operations kann in der Standardkonfiguration max. 10.000 Objekte verwalten. In hoch dynamischen Umgebungen, etwa mit virtuellen Desktops, in denen ständig neue VM's ausgerollt werden, entstehen leicht deutlich mehr Objekte.

Der Grund: vCenter Operations 'vergisst' nichts, und schleppt diese nicht existenten Objekte ewig mit.

Das Verhalten lässt sich leicht abschalten:

In der Analytics VM als root die Datei /usr/lib/vmware-vcops/user/conf/controller/controller.properties editieren. und die folgenden Eigenschaften anpasssen:

#Die automatische Löschung ungenutzter Objekte aktivieren
deleteNotExisting = true

#Dauer in Stunden die ein gelöschtes Objekt aufgehoben wird
deletionPeriodInHours=168

#In welchem Abstand in Stunden läuft der Müllsammler
deletionSchedulePeriod = 24

VmWare vShield App - das Geheimniss der boundaries.

Beim anlegen einer Regel in vShield App bin ich auf die ominöse Option "source boundary" bzw. "destination boundary" gestoßen. Man hat die Wahl zwischen "Inside" und "Outside", und auf den ersten Blick wurde mir nicht ganz klar, was sich dahinter verbirgt.

Der Admin Guide meint lapidar: "Direction in relation to source from which the communication originated.", was auch nicht wesentlich zum Verständnis beitrug. Also blieb nur: ausprobieren, und die Lösung ist dann am Ende doch recht simpel.

Die beiden unten stehenden Regeln lesen sich so:

Alles, was NICHT 'renton.ifbus.de' ist und mit Win7Flex kommuniziren will, wird geblockt. Alles was GENAU 'renton.ifus.de' ist, darf.

Sprich, die Option "Outside" ist einfach nur die Negation des verwendeten Objektes, wie man das Beispielsweise von Checkpoint kennt. Sprich: "Outside [Objekt]' als Destination erlaubt Verbindungen zu allen Zielen, außer eben zu 'Objekt', und umgekehrt.

VMWare vCenter Operations - IP Adresse ändern

Der Operations Manager von VMWare kommt als vApp, bestehend aus 2 virtuellen Maschinen, einer für's Userinterface (UI VM) und einer zum Datensammeln (Analytics VM).
Während des initialen Rollouts konfigurieren sich die beiden Maschinen gegenseitig, unteranderm werden dort die IP Adressen relativ fest im System verdrahtet.

Nun kann, je nach Umgebung, das versehen einer vApp mit IP Adressen mit unter recht hakelig sein, oder ein anderer Grund maht eine spätere Adressänderung notwendig. Da jedoch an den IP's verschiedene Konfigurationsparameter, Zertifikate etc. hängen, ist eine solche Änderung nicht eben schnell via ifconfig erledigt.

Darum im Folgenden eine kurze Anleitung, wie beide Systeme zu einer neuen IP Adresse kommen, und hernach trotzdem gewillt sind miteinander zu sprechen.

Ändern der Analytics VM

Fangen wir mit der Analytics VM an.

1.  Zuerst wird an der Konsole der UI-VM (defaultname: firstvm-external) der vcops Dienst gestoppt (ggf. vorher mittels sudo admin Rechte erwerben)  
• vcops-admin stop

2. Danach in der Analytics VM (defaultname:secondvm-external) in der Datei /etc/sysconfig/network/ifcfg-eth0 die IP Adresse ändern und via 'service network restart' das Netzwerk neu starten.
3. In der UI-VM muss nun die Konfiguration auf die neue IP angepasst werden, das geschieht mit dem Befehl 'vcops-admin repair --ipadress [neue IP der Analytics VM]' Wenn die Analytics VM unter der IP bereits erreichbar ist werden in diesem Moment auch die Dienste bereits neu gestartet.

Ändern der UI VM

1. Schritte 1-3 analog zur UI VM ausführen (Dienst stoppen, ifcfg-eth0 Datei anpassen und vcops-admin repair ausführen (Achtung: auch hier mit der IP der Analytics VM als Parameter.)).
2. Das vCenter vcOps Plugin muss nun noch über die Änderung informiert werden, denn dies kommuniziert mit der UI VM. 

• vcops-admin register update --vc-name [vc-name] --vc-server [https://vc-server/sdk] --username [vc-username] --password [vc-password] --force
  Über die Schalter '--collection-user' & '--collection-password' können auch Credentials für den Collectordienst mitgegeben werden, wenn dieser einen eigenen Systenmaccount verwendet.

  Hinweis: wer dies nicht über die CLI tun möchte kann sich auch via Browser in den Adminbereich der UI VM einloggen (https://[IP]/admin) und im Tab 'Registration' über den Button Update die Registrierung aktualisieren.

  
  

VMWare WSX: Zugriff auf VM's via Browser

Als teil der jüngsten Technology Preview bin ich über einen sehr interessantes Feature gestolpert: WSX.
Das ganze ist derzeit nur als Teil der Linux Version von VMWare Workstation verfügbar, und benötigt eine Python Umgebung (2.6).

Was ist WSX?
Im wesentlichen ist das ganze ein Dienst, der über jeden Html5 fähigen Browser angesprochen werden kann, und über eben diesen die Konsolen von virtuellen Maschinen darstellt. Und das nicht nur von lokalen Maschinen, sondern auch veröffentlichte VM's anderer Workstation Instanzen und sogar VM's von fremden ESXi Hosts.

Wozu das ganze?
Schwer zu sagen wann, ob und in welcher Form das Ganze in echte Produkte von VMWare einfließt. Dennoch setzt sich hier wohl die Strategie von VMWare fort, Applikationen oder ganze Konsolen via Html5 verfügbar zu machen, siehe Projekt AppBlast.