Beiträge

Veröffentlicht am

vSphere HA Features in der Zukunft: Restart Order

Auf der Seite Yellow-Bricks ist eine interessante Diskussion über ein mögliches neues Feature des HA Clusters entstanden. Duncan Epping von Yellow-Bricks ist selbst VMware Mitarbeiter. Er und einige seiner Kollegen diskutieren im Kommentarbereich mit Anwendern über eine mögliche neue Funktion und deren Gestaltung.

  • Definition von Abhängigkeiten (Ketten) zwischen VMs
  • Definition von Restart-Gruppen
  • Clusterweite Shutdown und Restart Richtlinien

Die Diskussion ist offen und jeder kann Anregungen zum Thema einbringen.

Veröffentlicht am

Verschiebung von VM in ActiveDirectory OU scheitert

Eine der Stärken von VDI Lösungen ist die schnelle Bereitstellung von VMs und deren automatische Registrierung im ActiveDirectory. Der hier beschriebene Fall bezieht sich auf ZeroClient VMs (ehemals Panologic), trifft aber auch auf andere Lösungen wie VMware Horizon View, oder Citrix XenDesktop zu.

Autodeployment

Erstellt man VMs mittels Autodeploy, kann man diese dabei in eine entsprechende OU des Active-Directory verschieben lassen. Im Fall einer Panologic Umgebung funktionierte dies lange Zeit problemlos. Nach Neugestaltung der OU wurden VMs aber nicht mehr in der richtigen OU abgelegt, sondern landeten in der OU „Computers“. Grund hierfür waren fehlende Rechte auf die OU für das Dienstkonto, welches die Verteilung erledigt.

PanoOUPermission01Folgende Rechte müssen gesetzt werden:

PanoOUPermission02Wird die Verteilung im Kontext des Domänen Admins ausgeführt (nicht empfohlen), so tritt das Problen natürlich nicht zu Tage. Hier wurde korrekterweise ein eigenständiges Dienstkonto für den Panomanager verwendet. Dieses hatte aber keine Berechtigung zur Objekterstellung in der Ziel-OU.

Veröffentlicht am

vCenter 5.5 Upgrade

Das Upgrade oder Update von vCenter auf Version 5.1 war mit einigen Problemen verbunden. Ich berichtete dazu in älteren Beiträgen (vgl. Links).

Auch das Upgrade auf die neueste Version 5.5 ist nicht ganz unproblematisch.

Testumgebung

  • vCenter 5.1 (1235232) installiert
  • Windows Server 2012 Standard, Build 9200
  • Alle Dienste (SSO, vCenter, DB) auf einem System
  • self signed Certificate (default)

Simple Install mit 1603 Fehler

Fehlerquelle 1 – Zertifikat

Bei selbstsignierten Zertifikaten, die sich nicht auf eine offizielle Stammzertifizierungsstelle zurückführen lassen, erscheint im Setup diese Warnung.upgrade55-01
Es ist wichtig das Zertifikat auf Gültigkeit (Ablaufdatum) und den korrekten Hostnamen von vCenter zu überprüfen. am einfachsten geht dies mit einem Browser.

https://FQDN:7444/lookupservice/sdk

upgrade55-02Die Warnung ist in Ordnung, da das Zertifikat selbst signiert ist. Daher das Laden fortsetzen.

upgrade55-03Die Details sieht man, indem man auf „Zertifikate anzeigen“ klickt. Es müssen zwei Dinge sichergestellt sein:

  1. Das Zertifikat ist nicht abgelaufen
  2. Es muss für den vollqualifizierten Namen (FQDN) des vCenter ausgestellt sein. Z.B. vc.mydomain.com

Registry

Der im Zertifikat hinterlegte FQDN muss ebenfalls in der Registry zu finden sein.

HKEY_LOCAL_MACHINE\Software\VMware, Inc.\VMware Infrastructure\SSOServer\

Im Key FqdnIp muss der vollständige Hostname hinterlegt sein. Im dargestellten Fall war der Key leer und damit die Ursache für ein gescheitertes Setup.

upgrade55-04Hier den FQDN des vCenter eintragen. Sollte hier eine IP Adresse registriert sein, so ist das lauf vmware KB auch eine mögliche Fehlerquelle. Was auch immer im Zertifikat steht, muss auch hier stehen!

upgrade55-05

 

  • Der Hostname lautet VC
  • Der FQDN lautet vc.mydomain.com
  • Die IP-Adresse lautet 192.168.1.35
  • Die Maschine gehört zu MYDOMAIN. Das Installationsprogramm verwendet den vorhandenen FQDN- IP-Wert aus der Registrierung: vc.mydomain.com

 Fehlerquelle 2 – Überbleibsel nach erfolglosem Upgradeversuch

Hatte man zuvor schon einen vergeblichen Upgradeversuch gestartet, so bleiben oft Verzeichnisse mit Updatedateien übrig. Für ein erfolgreiches Upgrade muss der gesamte CIS Ordner entfernt werden.

%ProgramData%\Vmware\CIS

Upgrade

Nach Bereinigung der Fehlerquellen 1 und 2 steht einem erfolgreichen Upgrade nichts mehr im Wege.

Links

Veröffentlicht am

LSIProvider verhindert ESXi Upgrade

In einem früheren Beitrag berichtete ich von Problemen beim ESXi Upgrade von Version 5.0 auf 5.1. Inzwischen wurde klar, daß es sich nicht nur um ein Problem in Zusammenhang mit angepassten Fujitsu Images handelt, sondern um angepasste Images allgemein.

Angepasste images

VMware liefert mit den ESXi ein limitiertes Angebot an Hardware Monitoring Tools, sogenannte CIM Provider. Viele Serverhersteller bieten erweiterte Monitoring-Funktionen, indem sie die nötigen CIM Provider in angepasste Images packen, und diese von VMware zertifizieren lassen. Der Vorteil ist ein besseres Hardware Monitoring im vSphere Client.

Problem mit LSIProvider

Vor einiger Zeit änderte LSI den Namen seines CIM Providers, was dazu führt, daß der Upgradevorgang (5.0 -> 5.1) des ESXi Servers mit dem Update Manager scheitert. Der Server bootet mit ESXi 5.1 und bringt am Ende eine Fehlermeldung, daß er den LSIprovider nicht aktualisieren konnte. Danach macht er ein Failback auf Version 5.0, aber die Installation verhält sich erfahrungsgemäß seltsam. So funktionierten einige esxcli Kommandos nicht mehr und manuelles Entfernen des VIB war nicht mehr möglich. Keine Installation, der man gerne vertrauen möchte. Ich wählte in diesem Fall die Neuinstallation. „LSIProvider verhindert ESXi Upgrade“ weiterlesen