Letzte Woche habe ich über eine Nachfolgelösung für VMware Server nachgedacht. Wenn man jedoch nach "VMware Workstation headless" googelt, lernt man, wie man auch die Workstation-Variante als Server missbrauchen kann.

Neben Cisco mit seinem Nexus 1000V Virtual Switch versucht nun auch Arista die virtuellen Switche im Management besser mit den physikalischen Switchen zu verknüpfen.

Ich betreibe seit langer Zeit zwei VMware Server 2.0, auf denen ein Server und einige Desktops laufen. Als Betriebssystem kommt CentOS 5.3 zum Einsatz und die VMs werden teilweise lokal und teilweise mit DRBD gespiegelt vorgehalten. Es gab und es gibt jedoch einige grundsätzliche Probleme: Als erstes musste ich das Betriebssystem und die VM's tunen, um eine einigermaßen befriedigende Disk-I/O-Performance zu bekommen. Die Benutzer der virtuellen Desktops klagen seit einiger Zeit aber wieder über Performanceprobleme, d. h.

Details sind im ThinApp Blog von VMware zu finden: http://blogs.vmware.com/thinapp/2010/08/vmware-thinapp-46-whats-new.html

Möchte man mit Hilfe des installierbaren ESXi selbst einen USB-Stick erstellen, von dem ESXi startet, findet man viele Anleitungen im Web. Wie dies jedoch auf einem Mac geht, findet man selten. Darum hier mein Vorgehen, einen bootfähigen ESXi USB-Stick anzufertigen.

Zuerst öffnet man das ISO-Images des ESXi (in meinem Fall die Datei VMware-VMvisor-Installer-4.1.0-260247.x86_64.iso) mit dem "Festplatten-Dienstprogramm":

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.