Datenfront

Bei einem meiner Kunden musste ein IP-Adressredesign stattfinden. Dazu mussten natürlich auch die IP-Adressen der ESX-Hosts und des vCenter Systems geändert werden.
Da direkt auch ein Upgrade des vCenter Servers auf die Version 4.0.x an stand hatten wir uns kurzfristig dazu entschieden das vCenter System komplett neu zu installieren auf einer neuen Plattform und nur die Datenbank zu übernehmen. Die ESX Server werden erst in der weiteren Folge auf die Version 4.0.0 aktualisiert, da es keinen funktionalen Grund gab dieses Upgrade zeitgleich umzusetzen. Gesagt getan, alle ESX Server wurden mit den neuen IP-Adressen "versorgt". Für eine Übergangszeit sollten beide IP-Adressbereiche erreichbar / erhalten werden, bis die endgültige Umstellung aller Servernetze abgeschlossen war. Soweit so gut. Alle Funktionen liefen vollkommen fehlerfrei und so sollte es auch während des Mischbetriebes bleiben.
Nachdem der endgültige Cut im Netzbereich vollzogen war liefen die ESX Systeme soweit auch fehlerfrei, allerdings informierte mich der Kunde darüber, dass er weder einen Klon-Prozess starten könne noch aus einem Template eine VM ausrollen konnte, immer mit der Fehlermeldung "failed to connect to host", obwohl der vCenter Agent aus dem vSphere Agent ansteuerbar war.
VMware KB Eintrag dazu: http://kb.vmware.com/kb/1010837

Ursache:

In der VPXDB waren nicht alle ESX Server IP-Adressen umgesetzt worden. Dort standen noch die alten IP-Adressen in der Datenbank!
Das reine ESX-Server aus dem vCenter herausnehmen und wieder hineinbringen brachte auch keine Lösung genauso wenig, wie das manuelle editieren der vpxa.cfg Datei

/etc/opt/vmware/vpxa/vpxa.cfg

, wie in manchen Foren beschrieben, da das vCenter immer Vorrang vor der lokalen Konfiguration hat, wird die falsche Einstellung mit dem Neustart des VPXA Agenten auf dem ESX Server erneut durch die falschen Parameter (IP-Adresse) aus der führenden Datenbank VPXDB ersetzt - per Push-Verfahren.

Lösung:

Die fehlerhaften Informationen finden sich in der SQl Datenbank wieder. Um diese Parameter ändern zu können muss das vCenter herutergefahren, sprich der Dienst beendet werden und die Datenbank darf nicht im Zugriff eines SQL Agenten sein. So dann kann man sich mit dem SQL Server Management Studio auf dem SQL Server anmelden, am besten mit dem VPXDB Benutzer, da dieser alle Berechtigungen für die Datenbank besitzt. Dann muss man die folgende Tabelle einmal aufrufen VPXDB.dbo.VPX_HOST und das folgende SQL Skript pro ESX Server ablaufen lassen:

UPDATE vcdb.dbo.VPX_HOST
SET IP_ADDRESS = ‘192.168.0.11’
WHERE DNS_NAME = ‘esxsrv011.domain.tld’

Wie immer im Verborgenen erblickte das neueste Kind von VMware das Licht der Welt. Das Update 3 ist da!
Da es in der bisherigen Version erhebliche Probleme mit der Berechnung der HA Kapazitäten in Verbindung mit dem UpdateManager und der benötigten vMotion Technologie gab, hat VMware diesen Schritt vorgezogen. Aber erstmal alles Schritt für Schritt:

Problem:
Insbesondere in kleineren Umgebungen mit zwei oder drei ESX Servern kann man einen produktiven ESX Server nicht mehr so einfach in den Wartungsmodus versetzen, insbesondere dann, wenn auch noch VMware HA auf Clusterebene eingestellt worden ist. Der Server startet mit dem Wartungsmodus und bleibt bei genau 2% stehen, bricht mit Fehler ab.
Betrachtet man af der Zusammenfassungseite die Clusterkonfiguration stellt man fest, dass die konfigurierte Failover Quote für HA auf ein Host eingestellt ist und die verfügbare Clusterkapazität den Ausfall von "NULL" Hosts erlaubt?!
Der kluge Administrator baut vor und hat extra für das kleine Cluster eingestellt, dass auch dann im HA Fall VMs neu gestartet werden, wenn die Kapazitätsgarantien für die VMs auf "erlaubt" gestellt.
Zusätzlich wurden die das.VmMemoryMinMB und das.VmCpuMinMHz gesetzt und trotzdem nix Wartungsmodus!?

Workaround:
Temporär die Clusterfunktion HA ausschalten. Die Konfiguration des Clusters geht dabei NICHT verloren (liegt in der VCDB) und im Anschluss an die Updateeinspielung wieder einschalten. Dabei wierden zunächst die Konfiguration und Pakete vom ESX Server deinstalliert und entfernt und im Anschluss wieder neu installiert.

Lösung:
Das Update 3 für VMware VirtualCenter behebt dieses Problem, auch in kleinen Clustern mit zwei bis drei Hosts klappt das einstellen des Wartungsmodus jetzt wieder problemlos und man kann auch über den UpdateManager wieder Patches einspielen.

demnächst mehr zum Thema VI 3.5 Update 3 hier!