Am 19.11.2009 veröffentlichte VMware das Update 1 für vSphere 4.0. Neben diversen Änderungen ist nun ein vi Client verfügbar, der sich unter Windows 7 nicht nur installieren sondern auch ohne weitere Verränkungen nutzen läßt (VMware-viclient-all-4.0.0-208111.exe).
Um die Spracheinstellungen des VMware Virtual Infrastructure Clients bzw. aktuell des vSphere Clients von bspw. deutsch auf englisch umzustellen, genügt es der Programmverknüpfung den Parameter ‚-locale en‘ mitzugeben. Umgekehrt wäre es ‚locale -de‘.
Um beim Windows 7 Setup das Auswahlmenü zu erhalten, welche Edition installiert werden soll, muß die ei.cfg Datei im Ordner ‚Sources‘ gelöscht bzw. umbenannt werden.
In dieser (Text-)Datei steht, welche Version das Setup automatisch installieren wird. Entfernt man die Datei, erscheint ein Auswahldialog in dem die Edition selektiert werden kann.
An die Datei gelangt man, indem man das Installations-ISO File entpackt (bspw. mit 7-Zip) bzw. den Inhalt der DVD auf die Festplatte kopiert.
Natürlich kann man den Inhalt der ei.cfg auch dahin gehend anpassen, um die zu installierende Windows 7 Version selbst festzulegen. Dafür editiert man den Abschnitt [EditionID] innerhalb der Datei.
Mögliche Eintäge sind:
Das vor ein paar Tagen festgestellte Problem mit der fehlenden msvcp71.dll nach einem VMware Tools Upgrade im %windir%system32 betrifft auch andere Applikationen. Im aktuellen Fall funktionierte die LAN Capi von AVM nicht mehr. Ein Server baut über einen AVM Ken! Client eine ISDN Verbindung zu verschiedenen Banken auf. Beim Versuch den Client zu starten erscheint aber wenigstens der Hinweis, daß o.g. dll-Datei fehlt.
Erneut von anderer Stelle ins System32 Verzeichnis kopiert, Ken!-Client Dienst neu gestartet und schon läufts wieder.
Habe heute die Prüfung zum VCP for vSphere 4 abgelegt. Wenn auch knapp aber doch bestanden 🙂
Die Vorbereitungen hätten durchaus besser sein können. Ich war überrascht, was dort alles abgefragt wird. Es geht wirklich quer durch alle Themen. HA, DRS, FT, Resource Pools, Storage Anbindung (gefühlt mehr FC als iSCSI), Netzwerk klassisch, distributed Switche, VMotion, Monitoring, Troubleshooting etc. Dabei werden aber nicht nur min/max Werte abgefragt sondern über geschilderte Situationen gezielte Einstellungen abgefragt. Die vorgegebenen Antworten sind sich oft ähnlich. Durch simplen Ausschluß blieben oft immer noch zwei Antworten übrig. 50/50 Chance wenn man sich nicht sicher ist 😉
Ich habe im Januar 09 den „Install & Configure…“ Kurs für 3.5 besucht. Im Oktober nun den „Whats new…“ für vSphere 4. Für die Prüfung habe ich 3 Abende gelernt.
Die gefundenen Braindumps im Netz kamen fast gar nicht in der Prüfung vor.
Nach dem kürzlich durchgeführten Update der ESX Farm auf vSphere 4 ließ ich den Update Manager mal testweise bei einigen VMs die VMware Tools und die Hardware Version updaten. Nach kurzer Zeit klingelt das Telefon, das Intranet geht nicht mehr. Ein kurzer Blick auf den Server verrät mir, daß die SQL Datenbank (SQL 2000 Desktop Engine) nicht mehr läuft, der Dienst läßt sich nicht mehr starten.
Der Update Manager erzeugt einen Snapshot der VM vor dem Update. Ich schob die Schuld auf den Snapshot, schließlich soll man das ja nicht mit DB Servern machen, stellte den vorherigen Zustand wieder her und beließ es mal vorerst bei der alten Version der Tools und vHardware Version.
Heute ‘spielte’ ich mit einer Kopie meines Intranetservers und führte nebenbei ein Update der VMware Tools durch. Da ich keinen Snapshot erzeugte sollte das ja ohne Probleme so nebenher gehen. Sollte….
Nach dem Neustart ging wieder der SQL Dienst nicht. Es schien also etwas mit dem Tools Update zutun zu haben. Einige Google Recherchen später fand ich heraus, daß es mit der fehlenden Datei msvcp71.dll zusammenhängen sollte. Ich erinnerte mich schwach, einen Hinweis auf eine eben solche dll ignorierenderweise weggeklickt zu haben da ich sie in den Zusammenhang mit den neuen Performance Countern gebracht und temporär für unwichtig gehalten hatte.
Eine Suche nach der msvcp71.dll auf der HDD der VM förderte mehrere Treffer zu tage, alle in der gleichen Version. Ich schnappte mir eine beliebige und kopierte sie nach %windir%system32.
Schon ließ sich der SQL Dienst wieder starten.
Ohne Worte…