Virtuozity

As I explained in Part 1 of this series there are some major drawbacks in the x86 architecture, especially when it comes to virtualization. VMware does the trick by using binary translation or how they call it: "Full Virtualization with Binary Translation". So, what's the deal with it?

To put it in a nutshell the VMware-Hypervisor rewrites problematical instructions for the VM in a way which should have the same effect on the VM compared to a traditional hardware-based system. So the application will probably get the same result. Sounds like emulation to you? Well, you are right. In fact, I/O and memory is emulated for the VM. The applications get partial direct access to the CPU to speed things up, e.g. non-privileged instructions in User-Mode. The guest OS works on Ring-1 and communicates with the underlying hardware via the "Virtual Machine Manager (VMM)" which works on Ring-0.

The good thing on Binary Translation is that you do not need to modify the guest OS itself, because the guest is not aware that is it virtualized. Also, from a security point of view binary translation delivers because of the high level of isolation of the VM and the independence of each system. On the other hand the Hypervisor will only run on supported hardware. Performance can also be a problem when things get a little bit "too emulated" on your VM. At least, now you know why.

Why did it take so long for virtualization technology to evolve on the x86 architecture? The problem is the architecture itself, as I will explain in a moment. For a long time x86 virtualization was actually thought to be impossible. The OS works in the so-called Ring-0, often better known as the "Kernel-Space", while the applications use Ring-3, mostly referred to as "User-Space".

What you have to do, is to separate the OS from the hardware. But there is more to it, since there are known privileged instructions and some sensitive instructions which deliver different results depending on the Ring they are executed in. Some of these are able to change the CPU state and have to be run in Kernel-Space, an execution in User-Space has to result in an exception. This is where the problem starts, because classic x86 CPU's are not able to except all kinds of instructions. The solution could be to except all instructions and emulate them in a proper way. But is this really the way to do it?

At this moment there are three major virtualization solutions in the industry which deal with these problems in different ways:

• Binary Translation
• Paravirtualization
• Hardware Assisted Virtualization

I encourage you to look into my future postings to learn more about these virtualization technologies.

Mit dem neuen VMware View wird die VDI-Lösung des Virtualisierungsmarktführers erwachsen. Mit neuen wichtigen Funktionen räumt VMware die Hauptkritikpunkte am VDI-Konzept souverän aus dem Weg.

Thin Cloning

View nutzt die Snapshot-Technologie von VMware um platzsparende Klone aus einem "Golden Master" zu erzeugen. Lediglich die Änderungen am System werden individuell mitgeschrieben. Hier wird sich zeigen müssen, ob diese Funktion von der Performance her im Enterprise-Umfeld überzeugen kann. Die Storage-Ersparnis ist jedoch in vielen Fällen erheblich.
Diese Technologie bietet noch einen weiteren Vorteil: Patching oder zentrale Konfigurationen am Betriebssystem können zentral am Golden Master vorgenommen werden und wirken sich auf alle Klone aus.

ThinApp Integration

Mit dem Kauf von Thinstall hat sich VMware ein leistungsfähiges Produkt zur Applikationsvirtualisierung ins Boot geholt. Konsequenterweise wurde ThinApp in View integriert und erleichtert die Verteilung und Pflege von Anwendungen damit erheblich.

Thinprint Kooperation

Die virtuelle Print-Lösung hat sich bereits seit Jahren am Markt bewährt und löst eines der Hauptprobleme im VDI-Bereich. Die Drucker-Verwaltung mit dem allseits bekannten Treiber-Chaos hat damit endlich ein Ende.

Offline Desktop

Was ist, wenn ich kein Netz habe? Diese überaus berechtigte Frage mussten sich VDI-Verfechter bislang zu Recht gefallen lassen. View löst dieses Problem durch eine Replikationslösung, die die VM auf das Notebook replizieren kann, um ohne Netz arbeiten zu können.

Trotz aller VDI-Euphorie sollte man eine solche Lösung mit spitzem Bleistift kalkulieren. Aus meiner Sicht lohnt sich VDI aktuell nur unter Sicherheitsaspekten. Prozessor-, Hauptspeicher- und Storage-Kapazitäten kosten zentral gewartet nämlich deutlich mehr. Aktuelle PC-Prozessoren sind extrem leistungsfähig und stehen ihren Brüdern im Serverumfeld kaum nach, da Intel und AMD sich keinen zweiten Entwicklungszweig leisten wollen. Hochverfügbarer Storage kostet ein Vielfaches im Vergleich zur günstigen SATA-Platte in Notebook oder Desktop-PC. Da die Programmierer um die geballte Rechenpower wissen, optimieren sie dementsprechend wenig, weil Optimieren viel Geld kostet und die Produktkosten erhöhen würde. Soll heißen, dass aktuelle Anwendungen die Hardware häufig auch entsprechend fordern.

Link: http://www.vmware.com/download/shared_utilities.html

Wer verschiedene Server-Typen zusammen in einem Cluster betreiben möchte und sich unsicher über deren Verhalten im Zusammenspiel ist, wird sich vermutlich über das "CPU Identification Utility" von VMware freuen. Enthalten ist ein ISO-Image zum Booten des Hosts, das Aufschluss über VMotion Kompatibilität sowie der Unterstützung bezüglich EVC und 64bit gibt.

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

Lange hat es gedauert, jetzt ist es endlich soweit: Für den ESX-Fehler im Update Release 3 ist ein Patch verfügbar. Dieser Bug ist zwar bei den meisten Kunden gar nicht aufgefallen, die Auswirkungen wären jedoch eher dramatisch gewesen. Beim Failover im SAN wurde der Zugriff auf die LUNs vollständig blockiert, falls während des Pfadwechsels VMFS-Metadaten geschrieben wurden. Als einzige Lösung blieb ein Reboot des Hosts übrig.