Archiv der Kategorie: VMware

Auf manchen vmware vSphere Hosts macht sich diese Fehlermeldung im gelben Informationsbereich bemerkbar und versetzt den Host auch noch in den fiesen be-Warndreieckten Warnstatus:

"Dieser Host verfügt momentan über keine Verwaltungsnetzwerkredundanz"

Die Meldung stammt von dem eifrigen Management-Agent des ESX Hosts und hat eigentlich einen guten Grund. Das Verwaltungsnetzwerk („Management Network“) sollte (dringend) mit mindestens zwei Netzwerkkarten angebunden sein, denn sonst könnte ein Gast mit viel Traffic (sofern im selben Netzwerk) das Management erheblich stören. In der wundervollen heilen vmware-Welt hat natürlich jeder Host mindestens zwei Netzwerkkarten für die Verwaltung, zwei oder mehr für vmotion, eine für den Cluster-Takt (und vielleicht FT) und dann noch mindestens vier für Gastsysteme – pro Netzwerk versteht sich. Da Hosts mit neun oder mehr Netzwerkkarten in der KMU-Welt mit unter zehn ESX-Hosts eher selten anzutreffen sind, erübrigt sich diese Warnung in vielen Fällen.

Sollte diese Meldung einmal trotz redundanter Anbindung auftauchen und nicht wieder freiwillig verschwinden, hilft oft einer dieser beiden Tricks:

• Entfernen einer der beiden Netzwerkkarten von dem virtuellen Management-Switch, dann erneutes hinzufügen … 20 Sekunden warten.
• Oder: Rechte MT auf den host un „HA-Agenten neu konfigurieren“

Sollte das nicht helfen, tut aber auf jeden Fall die rohe Gewalt:

1. Eigenschaften des Clusters öffnen
2. vSphere HA -> Erweiterte Optionen
3. Hinzufügen der neuen Option:

    das.ignoreRedundantNetWarning   True

4. Ok -> OK -> OK -> HA-Agent neu konfigurieren.

Dann ist die Warnung weg und erscheint auch bei keinem Host im ganzen Cluster wieder. jemals. auch nicht, wenn Sie recht hätte.

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.

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.