vSphere Appliance VC_CFG_RESULT=302(Error: Enabling Active Directory failed.)

Ab und an kommt es bei der Inbetriebnahme einer vSphere 5 oder 5.1 Appliance zu dem folgenden Fehler:

VC_CFG_RESULT=302(Error: Enabling Active Directory failed.)

Dieser kann mehrere Ursachen haben. Fehlersuche:

  • Ist die vCenter Applicance mit dem richtigen LAN verbunden, hat es eine korrekte IP-Adresse, eine passende Subnetzmaske und/oder passeden routen zu DNS/AD-DCs? (vSphere Clients, VM bearbeiten, Netzwerk – danach https://<vcnetername>:5480)
  • Hat die Adresse der Appliance schon einen korrekten DNS-Hosteintrag und den passenden reversen Pointer für diesen Namen (als einziges)? Der Eintrag muss tatsächlich dem Namen der Appliance entsprechen, sonst schlängt die Zertifikatsprüfung fehl und es darf nicht mehrere geben

    .

  • Steht bei der Benennung der Appliance (https://<vcentername>:5480 – Network) der ganze FQDN drin?
  • Ist bei der Angabe der Active Directory Domain der vollständige FQDN der Domäne eingegeben?
  • Steht die Zertifikatsgenerierung (System – Toggel Vertificate genration) vielleicht auf „no“? Die sollte auf ‚yes‘ stehen, bis alles läuft.
  • Ab und zu hilf es, den Admin-UPN (administrator@domä.ne) zu verwenden, anstalle des einfachen Benutzernamens.
  • REBOOT. Nach der Integration Rebooten, sonst funktioniert die Auswahl nicht oder das domänen-Feld bleibt gleich ganz leer.

Nach Prüfung aller dieser Ursachen kommt eigentlich nur noch DNS oder ein falsches Administrator-Kennwort in Frage. Im Internet kursieren Tipps, den Hostnamen des vCenter Servers manuell im AD anzulegen. Das ist nicht notwendig, die Vertrauensstellung wird selbstständig erzeugt. Wenn alles korrekt funktioniert.

VMWare ESX(i) Datastore Heartbeat ausschalten

Ich wurde jetzt ein paar Mal gefragt, ob und wie man den Datastore-Heartbeat komplett auschalten kann. Eigentlich gibt es nicht wirklich einen Grund dafür, aber es gibt bestimmt Sondersituationen in denen das angebracht ist.

Lösung:

  • vSphere Client mit dem vCenter verbinden, Eigenschaften des Clusters öffnen
  • Einstellungen bearbeiten -> Datastore Heartbeat
  • Datenspeicher auswählen
  • Hier keinen Datastore auswählen

Das ist schon alles. Allerdings raten wir von dieser drastischen Maßnahme ab, es sei denn man weiss genau was man tut.

Windows 8 vCenter Converter 5.0 error: „Crypto exception: error:02001005“

vmware_vcenter_converterBeim Erstellen eines Konvertierauftrages im (derzeit) aktuellen vCenter Converter 5.0.1 wird das Sammeln der Ziel-Informationen durch diese Fehlermeldung unterbrochen:

A general system error occurred: Crypto Exception:
error:02001005:system library:fopen:Input/output error:unable to
load C:ProgramDataVMwareVMware vCenter Converter
Standalonesslrui.crt

Es werden keine Informationen gesammelt, die Zielmaschiene kann nicht konvertiert werden.

Lösung:

Der Converter muss (vor allem unter Windows 8) zwingend „Als Administrator“ ausgeführt werden. Rechte Maustaste auf den Converter und „Als Administrator“ ausführen. Selbst das „Ausführen als anderer Benutzer …“ mit der auswahl eines Admins genügt nicht.

vCenter Server für Windows „SQL Fehler 25003“ „Setup failed to create the vCenter Server repository“

Manchmal trifft man ja noch auf vCenter Server unter dem Windows (Server) Betriebssystem. Seit der offiziellen vmware-Appliance ist das zwar seltener geworden, kommt aber ab und an noch vor. Manchmal schlägt die Installation und/oder das Update des vCenter Servers aber mit dem SQL-Fehler 25003 und meist noch mit dem Zusatz Setup failed to create the vCenter Server repository fehl.

Lösung:
Den ODBC-Treiber in der Konfiguration der zugehörigen DSN in der Systemsteuerung auf „Englisch“ umstellen:

  • „change language of system messages to English“ einschalten
  • „Perform Translation For Character Data“ ausschalten
  • „Use Regional Settings When Outputting Currency, Numbers, Dates, And Times“ ausschalten

vSphere ESX(i) 5.1 vpxa manuell entfernen

Aus Gründen kann es ab und an mal vorkommen, dass ein vCenter Server entfernt werden musste – zum Beispiel physikalisch. Die übriggebliebenen ESXi-Hosts bleiben in so einem Fall stets der Meinung, auch weiterhin von dem vCenter Server verwaltet zu werden:

Dieser Host wird derzeit von vCenter Server uner der Adresse 1.1.1.1 verwaltet. Änderungen die Sie während dieser Sitzung am Host vornehmen, werden in aktuellen vSphere-Clientsitzungen mit vCenter Server möglicherweise nicht wiedergespiegelt“

Mit einem neuen vCenter Server lassen sich diese Hosts zwar sofort wieder verbinden, aber was passiert wenn es keinen vCenter Server mehr gibt? Um die lästige Meldung loszuwerden reichen zum Glück ein paar Schritte.

Lösung:

  1. SSH Server starten und den Zugriff erlauben (Konfiguration -> Sicherheitsprofil)
  2. Via SSH (z.B. mit PuTTY) am Host als root (oder Benutzer mit Rechten) anmelden
  3. Die vpxa Config bearbeiten (/etc/vmware/vpxa/vpxa.cfg)
    vi /etc/vmware/vpxa/vpxa.cfg
  4. Die ganze Sektion „<vpxa>“ bis „</vpxa>“mit Inhalt entfernen und mit :wq speichern/beenden. Sollte vi der Meinung sein, das die Datei viel zu schreibgeschützt sei, lässt sich dieser mittels einem
    chmod +w /etc/vmware/vpxa/vpxa.cfg

    aufheben.

  5. Vpxa und vmware Hostd neu starten
    /etc/init.d/vpxa restart
    /etc/init.d/hostd restart

    Dann den vSphere Client neu verbinden, fertig.