Typisches Szenario: vCenter 4.0 ist auf einem 32-Bit System installiert und das anstehende Upgrade auf 4.1 benötigt ein 64-Bit System, auf welches migriert werden muss. Fährt man dabei eine MS SQL Express 2005 Datenbank als Unterbau, kann man das Data Migration Tool nutzen, um die Migration durchzuführen. Außer man stolpert dabei über folgenden (wohl bekannten) Fehler.

[INFO] [INFO] Msg 8114, Level 16, State 1, Server VCENTER\SQLEXP_VIM, Line 1 Error converting data type bigint to int. Msg 3013, Level 16, State 1, Server VCENTER\SQLEXP_VIM, Line 1 RESTORE FILELIST is terminating abnormally.
[ERROR] Error: vCenter Server DB backup failed
[ERROR] Exiting…

Der genaue Verursacher ist unbekannt, das soll jedoch nicht stören, denn immerhin gibt es einen recht einfachen Workaround. Diesen Beitrag weiterlesen »

2010 ist vorbei, der weihnachtliche Winterschlaf auch, und 2011 wird fraglos wieder im Zeichen von Virtualisierung und der vielbemühten – aber deutlich handfester werdenden – Cloud stehen. Während andere in der V-Blogosphäre über 2010 resümieren (u.a. hier, hier, hier, hier oder bei John Troyer’s VMware-Communities-Roundtable-Jahres-Review), wollen wir einen kurzen Blick nach vorne werfen und uns kurz eine Idealwelt ausmalen, in der Hersteller etwas von dem umsetzen, was man so braucht. Wie sähe so ein Wunschzettel aus? Diesen Beitrag weiterlesen »

vCenter kommt bekanntlich von Haus mit der kostenfreien SQL Express 2005 Edition zur Datenhaltung daher. Neben weichen Dimensionierungsrichtlinien wie max. 5 ESX Hosts und 50 VMs, gibts eine sehr harte Richtlinie und die lautet: max 4GB an Daten.

Wie man diese Grenze schneller erreicht als geplant (sprich mit einem deutlich höheren Bedarf als vom DB Calculator veranschlagt), haben wir die Tage unfreiwillig bei einem Testsetup herausgefunden: 7 ESX Hosts und 162 VMs, testweises Monitoring durch Nagios und OP5s check_esx3.pl, bei Datenmigrationsarbeiten dann plötzlich die Datenbank am Anschlag. Diesen Beitrag weiterlesen »

Ich bin (k)ein großer Freund von obskuren Fehlermeldungen …

• Ausgesprochener Freund, weil dabei der Lösungsinstinkt anspringt.
• Kein Freund, weil solche Meldungen klarerweise nicht sonderlich benutzerfreundlich sind.

Neulich beim VM-Deployment von einem fremderstellten 2008 Template gab es wieder eine besonders hübsche Fehlermeldung nach dem Klick auf ‘Finish’. Lösung anbei, um zukünftigen Problemsuchenden schneller auf die Sprünge zu helfen:

Clone virtual machine w2k8-se-de-64bit Customization of the guest operating system ‘winLonghorn64Guest’ is not supported in this configuration. Microsoft Vista (TM) and Linux guests with Logical Volume Manager are supported only for recent ESX host and VMware Tools versions. Refer to vCenter documentation for supported configurations.

Zugrunde lag dem keinesfalls eine Inkompatibilität, sondern lediglich eine fehlende VMware Tools Installation im Template … und ohne die Tools funktioniert das Customizing klarerweise nicht, denn dazu müssen Dateien und Befehle ins Gast-OS injiziert werden (ähnlich wie das übrigens die Virtual Guest Console macht und diese benötigt auch zwingend die Tools). Also VMware Tools installiert, weitere individuelle Anpassungen am Template vorgenommen und sich am einwandfrei funktionieren Deployment erfreut.

Man muss Sie einfach lieben, die Blogosphäre. Auf der VMworld Session zu “Advanced esxtop” hatte ich mich mit einer der esxtop-Entwicklerinnen unterhalten, weil wir auf High-Density-VDI-Servern zu viele VMs haben, als dass sie einfach im esxtop verwaltbar sind. Sprich: bei ~100 VMs reicht das Terminal-Fenster einfach nicht aus, um eine relevante VM zu identifizieren und dann die Anzeige mit der in esxtop 4.1 hinzugekommen Limit-Option einzugrenzen.

Meine Wunschvorstellung: Die Ausgabe interaktiv auf bestimmte VMs eingrenzen zu können, entweder anhand des Namens (anstatt der GID) oder direkt beim Aufruf von esxtop in Form eines Kommandozeilen-Parameters (auch wieder namensbasiert).

Diesen Beitrag weiterlesen »