Im Rahmen einer Migrationsplanung von VI3 auf vSphere4 möchte ich auch das Thema Kapazitätsplanung in den Griff bekommen. Meine Analysen der aktuellen Umgebung haben gezeigt, dass in absehbarer Zeit zuerst der Arbeitsspeicher und dann der Plattenplatz knapp werden wird.

In der aktuellen Version der ESX-Server wird statt eines MD5 Hash nur ein DES Hash verwendet, um Passwörter in /etc/shadow zu speichern. Deshalb sind bei der Passwortüberprüfung lokaler Benutzer nur die ersten 8 Zeichen relevant.

Aus meiner Sicht ist dies nicht wirklich beunruhigend, aber es zeigt, dass bei VMware gerdade doch einiges mit sehr heißer Nadel gestrickt wird. Von einem Update auf vSphere 4.1 werde ich im Moment auf jeden Fall noch noch absehen.

Leider wird das Thema “Kompatibilität” zum Dauerbrenner, denn nicht jedes VMware-Produkt kann mit jeder vSphere-Version zusammenarbeiten. Nutzt man aktuell den VMware View Composer 2.0.x bedeutet dies für das Update auf vSphere 4.1 ein “no go”. Der vCenter-Server von vSphere 4.1 benötigt zwingend ein 64bit OS als Unterbau, der Composer mag aber nur 32bit Betriebssysteme, schade!

Seit rund 10 Tagen bin ich nun ein sehr glücklicher iPad-Besitzern und langsam verliert mein kleiner Sohn etwas das Interesse am grossen "eiff" (Clemens für "iPhone" - inzwischen weiß er aber auch, dass es ein iPad ist). Während der ersten Tage musste ich das iPad immer wieder samt Tastatur aufbauen, damit er damit "arbeiten" konnte. Und nachdem ich ihm einmal einen "Petterson und Findus" Film auf Youtube gezeigt habe, weiß er natürlich auch, wie er Youtube auf dem iPad starten kann.

VMware View zielt auf ein Marktsegment, dass in der Vergangenheit von CITRIX dominiert wurde. Dachte man in der Vergangenheit an zentral gehostete Applikation oder Terminalserver, dachte man an CITRIX. Durch das Thema Virtuelle Desktops kommt jetzt jedoch Bewegung in Spiel. Da ich inzwischen einige gute Erfahrungen in VMware View Projekten gesammelt habe, ist es Zeit, sich mit den Alternativen auseinander zu setzen. Denn eines ist für mich klar, virtuelle Desktops (VDI) können nur ein Baustein einer sinnvollen Desktopstrategie sein.

Letzte Woche bin ich bei einem Kunden auf spannendes Problem gestoßen: Wir hatten den VMware View Security Server neu aufgesetzt und wollten jetzt testen, ob der auch funktioniert. Zuerst der Zugriff aus dem Internet - nichts! Dann lokal auf dem Security Server mit https://localhost - nichts, jedes mal ein Timeout! Dabei kann man ja eigentlich bei der Installation eines Security Servers nichts falsch machen, oder doch?

Gestern Abend bin ich so kurz nach 20:00 Uhr von einer mehrtägigen Dienstreise heimgekommen. Meine Frau und unser fast dreijähriger Sohn Clemens waren gerade bei der Einschlafzeremonie. Kaum hatte Clemens mich jedoch gehört, flitzte er die Treppe herunter und zeigte hektisch auf einen Stapel Pakete: "Das auspacken! Das auspacken!"

Gemeinsam haben wir dann den iPad, die Tastatur mit iPad-Dock und die Apple Tasche für den iPad ausgepackt. Clemens war sichtlich entäuscht, daß der iPad zuerst mit iTunes synchronisiert werden wollte und er ins Bett musste.

Beim Aufsetzen einer neuen VMware View 4 Umgebung, habe ich gerade festgestellt, dass folgende Aussage aus dem View 4 Admin Guide ("view401_admin_guide.pdf") nicht ganz richtig ist: Assign the View Manager administrator the role of administrator for a datacenter or cluster where pools will be created so that they can make the required changes.

Wenn man einen vSphere4 ESX-Server mit Standardeinstellungen installiert, ergibt sich in etwa folgendes Filesystemlayout:

Ich habe mich entschlossen, dieses Blog in vLeygraf.de umzubenennen. Das geschieht zum einen, weil man sich vLeygraf.de leichter merken kann. Zum anderen möchte ich, dass dieses Blog mehr mit meinem Namen und damit mit mir verbunden wird.

Was meint ihr?