Sysprep einer Template VM mit Windows Server 2008R2 schlägt fehl

Thursday, 23 October 2014 10:29:04 (W. Europe Daylight Time, UTC+02:00)
Während der Installation einer neuen VM kommt es in der Sysprep Phase zu folgendem Fehler:
"Die Antwortdatei [SYSPREP] konnte nicht analysiert werden..."
Diese Fehlermeldung bleibt auch nach dem Neustart der VM erhalten und die Installation scheitert.



Dieser Fehler beruht auf einer fehlerhaften Installations PID für die Windows Instanz. Das heisst der Server/ die VM wurde aus einem Template erzeugt, dass nicht aktiviert war.
Die Lösung ist also denkbar einfach:
1.Template in VM umwandeln
2. Template-VM starten
3. Windows aktivieren <-- Das ist der Punkt
4. VM wieder in ein Template verwandeln
VMware hat dazu einen Knowledgebase Artikel veröffentlicht, den findet man hier

VMware vCenter Certificate Automation Tool ist verfügbar

Monday, 08 April 2013 10:33:38 (W. Europe Daylight Time, UTC+02:00)
Seit langem existierte ein internen Werkzeug zum erstellen und Einbinden von CA SSL-Zertifikaten für den Einsatz unter VMware.
Leider war das Werkzeug nicht öffentlich verfügbar oder einfach schwer versteckt für die Öffentlichkeit.
Mit der Einführung von VMware vSphere 5.1 wurde die SSL Implemntierung zu einer wahren Odysee und so habe ich in vielen Projekten sehr viel länger mit der Implementierung gebraucht, als vorgesehen und gedacht (trotz Puffer ;-) ).



Das Werkzeug steht jetzt offiziell in der Download Seite bereit unter:
http://vmware.us2.list-manage2.com/track/click?u=6a06ad2174e3a4b4095b5f746&id=d65ec5760a&e=d3a2611a8d
Und trägt den Namen vCenter Certificate Automation Tool. Ob das Ganze auch sauber in den Appliances funktioniert muss sich zeigen.
Manuell ließen sich die Zertifikate dank einiger neuerer KB Artikel erstellen, allerdings gab / gibt es mit der SSL Implementierung auf der Appliance noch so manche Nuss zu knacken.
Das neue Werkzeug wird in der KB von VMware auch beschrieben unter:
http://kb.vmware.com/kb/2041600

Ich werde es in der nächsten Zeit auf Herz und Nieren testen :-D

VMware SSO 5.1.0a Update - Achtung!!!

Friday, 26 October 2012 10:58:38 (W. Europe Daylight Time, UTC+02:00)


Wer bisher bereits auf vSphere 5.1 setzen wollte kam um eine neue zentrale Komponente nicht herum,
den neuen VMware SSO Server. Dieses Produkt wurde entwickelt um MUlti-Tenant Umgebung an das vCenter zu binden,
da man ja den Windows Rechner nur in einen Forrest hängen kann :-D

Mit dem schnellen Release von Version 5.1.0a der Software muss zwingend das Update über die CMD gemacht werden, sonst kann es auf nicht englischen Windows Instanzen zu einem Problem, Abbruch der Installation kommen!

VMware hat dazu einen Knowledgebase Artikel bereitgestellt unter:

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




Der Update Prozess bleibt für den Anwender so lange unsichtbar, wie er ihn nicht mit einem Logfile Viewer beobachtet. Das geht hervorragend unter Windows mit der Freeware / Shareware mTAIL, die man auch mit mehreren Log-Files parallel füttern kann. mTAIL kann man hier herunterladen:
http://ophilipp.free.fr/op_tail.htm

Also keine Angst wenn der Cursor nach dem Abwurf der Befehlszeile direkt umspringt!

vCenter DB veraltete IP-Adresseinträge der Hosts löschen

Wednesday, 31 March 2010 16:21:40 (W. Europe Daylight Time, UTC+02:00)
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’


Im Anschluss kann das vCenter System neu gestartet werden (Dienst oder ganzer Server) und die VPXA Agenten ziehen sich die "richtige" Konfiguration aus der Datenbank. Danach funktionierte dann wieder alles wie gewohnt, klonen, Templates, svMotion etc.

VMware Virtual Center 2.5.0 Update 3 ist da!

Saturday, 04 October 2008 07:46:08 (W. Europe Daylight Time, UTC+02:00)
Das jüngste Update Paket für das VirtualCenter beseitigt unter anderem Probleme mit dem Wartungsmodus & dem UpdateManager!



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!