Microsoft Hyper-V! Treten Sie einen Schritt zurück

Wie angekündigt, war ich gestern auf der Veranstaltung von Microsoft, die das Thema Hyper-V behandelte.

Als ich das erste mal was von Microsoft und Virtualisierung gelesen habe habe ich gedacht, dass Redmond einfach VMware aufkaufen wollte, um sich alle weiteren Mühen zu sparen. Aber dem war nicht so! Microsoft unternimmt tatsächlich den Versuch auf den Virtualisierungs-Zug aufzuspringen. Mehr oder weniger erfolgreich wie ich finde.

Auf der Veranstaltung war nun ein Redner, der die Zuhörerschaft davon überzeugen sollte/wollte, dass Hyper-V ein tatsächliches Konkourrenz-Produkt zu ESX VI3 sei. Bereits nach 5 Minuten war allen klar, dass es für ihn ein gutes Stück arbeit wird 🙂

Aber nun zu dem Produkt selber:

Um Hyper-V nutzen zu können, benötigt man einen installierten Windows 2008 Server 64bit (Std, Enterprise, Datacenter). Die Editionen machen hierbei nur einen Unterschied in der Lizenzierung (Std: 1VM, Enterprise: 4 VM’s, DataCenter: unlimited VM’s). Seinem installieren Server weist man dann die Rolle „Hyper-V Beta“ zu. Nachdem man diese aktiviert hat, kann man aber mit WSUS oder ähnlichem die Version RC1 des „Hyper-V“ nachziehen, dann verschwindet auch das Beta.

Nach dem nächsten Reboot passiert folgendes. Zwischen Hardware und den Windows Server 2008 x64 wird der „Hypervisor-Layer“ geschoben. Somit ist der vorher installierte Server schon die erste virtuelle Maschine auf dem Sytem (Parent Partition). Oben auf der Parent-Partition sitzt nun der „Virtualization Stack“. Das war schon das erste, wo ich ein bisschen geschluckt habe. Legt man nun via VMM (Virtual Machine Manager) einen neuen Server an, ist dieser auch sofort virtualisiert und nennt sich (Child Partition). Der gesamte Datenstrom (NIC, I/O, etc…) läuft über den „Virtualization Stack“ der Parent Partition. Legt man eine weitere Maschine an, passiert das selbe. Alle Daten über die Parent Partition. Die Treiber für die virtuelle Hardware werden übrigens auch noch von der Parent Partition gestellt 🙂

Anhand dieses Bildes (was mich sehr an eins von VMware erinnert) kann man sich das ganze recht gut vorstellen. Alles rechts der Parent Partition greift auf die selbige. Diese schleift dann das ganze auf den Hypervisor und der wiederum auf die physikalische Hardware durch. Im allgemeinen nennt man sowas glaube ich „Bottleneck“ 😉

Aber das Problem scheint Microsoft selber schon in der Entwicklung erkannt zu haben und hat schnell noch was dazu gebastelt. Dazu muss ich jetzt noch ein Bildchen heranziehen, dass ein bisschen verwirrender aussieht. Aber daran kann man das ganze recht gut erklären. Lasst euch von den Pfeilen nicht irritieren, die haben in dem Zusammenhang keine Bedeutung.

Normal ist jede VM mit einem „VMBus“ augestattet. Über den greift sie dann auf den „Virtualization Stack“ der Parent Partition zu. Es gibt allerdings noch eines von diesen tollen Features, die eigentlich gar keine sind, weil sie ein anderes Feature unverfügbar machen. Das nennt sich dann „Emulation“ man kann also auch Hardware in einer VM emulieren. Diese emulierte Hardware greift dann direkt auf den Hypervisor zu. Das geht aber soweit ich das gesehen habe nur mit NIC’s, da Platten-Devices auch an der „Parent Partition“ sichtbar sein müssen um auf einer VM zu funktionieren. Da werden die Daten dann einfach trotz emulierter Hardware durch die „Parent Partition“ geschleift.

Eines der besten Features der Virtualisierung fehlt komplett. Mehr Speicher zuweisen, als die physikalische Hardware bietet, um den Speicher optimal auszulasten. Kurz „Memory OverCommitment“. Man kann den VM’s nur so viel Speicher zuweisen, wie die Physik tatsächlich bereit stellt. Also 8GB Speicher wären 4 VM’s mit 2 GB Speicher, oder 1VM mit 8GB Speicher, usw… Das hat bei mir das zweite, wirklich grosse Schlucken verursacht, weil sich das auch auf spätere „Features“ auswirkt.

Quick-Migration nennt Microsoft das, was bei VMware VMotion heisst. Der einzige Unterschied ist, dass bei Microsoft ein Ausfall von bis zu 5 Minuten entsteht. Bei VMware geht das online. Ausserdem funktioniert Quick-Migration auch nur dann, wenn auf der anderen Maschine genug Speicher frei ist, dass die VM darauf laufen kann. Habe ich den ganzen Speicher der Maschine schon besetzt (sollte normal so sein), fliegt die VM ins Nirvana. Gehe ich von einer Standard-Config aus, haben meine VM’s 2048MB Speicher. Gehe ich davon aus, das ich 10 VM’s habe, sind das 20GB. Das heisst, ich muss auf jedem Host einige GB Speicher frei halten, damit die VM’s da überhaupt ankommen. Bei einer Config mit 2 Servern wären das 20 GB auf dem anderen Server. Aber da das meistens keinen Sinn macht, muss ich mir ja doch noch ein Stück zusätzliches Blech kaufen, damit die VM’s zuverlässig laufen. Dieses Stück Blech läuft dann aber immer nur auf sehr geringer Auslastung, weil ich den Speicher ja frei halten muss… Irgendwie, Naja weiss nicht ob das der Gedanke ist, der hinter der Virtualisierung steckt. Bei einem ESX Server mit dem selben Setup sollte man auch den Speicher freihalten – „sollte“. Es funktioniert aber auch, wenn er nicht frei ist. Die Maschine läuft zwar sehr langsam, aber sie läuft! Bei Hyper-V funktioniert es dann einfach nicht…

Sogar Betriebssyteme wie Linux sind als VM supported! Allerdings macht sich hier schnell Ernüchterung breit.

Supported CPU’s for Operating-Systems:

Windows Server 2008: 4 CPU’s

Windows Server 2003: 2 CPU’s

Windows Server 2000: 1 CPU

Linux + others: 1 CPU

Mit einem Linux System, dass nur 1 CPU benutzen darf, kann ich nicht wirklich viel anfangen 🙁

Aber eine tolle Konstellation ist möglich! Ich habe eine Linux-VM auf Microsoft virtualisiert, so wie vorgeschrieben. Dann kann ich einen Call bei Microsoft für mein virtuelles Linux aufmachen, wenn ich ein Problem habe 😀

Allerdings ist, glaube ich, bis jetzt nur SLES 10 supported 🙁

Meine persönliche Meinung zu Hyper-V ist, dass es in Sachen Virtualisierung ein gewaltiger Schritt zurück ist. Der Gedanke der hinter der Virtualisierung steckt, wurde bei Microsoft durch den Marketing-Wolf gejagt und die Soße, die unten raus kam wurde in Code (sprich: Kot) umgesetzt. Mit einigen Service-Packs in der Zukunft und Patches könnte das vielleicht mal interessant werden. Stand heute würde ich allerdings die Finger davon weglassen, weil damit meistens die Anschaffung zusätzlicher Hardware verbunden ist (wie ironisch) 😀

Meine Anfrage nach dem „Konsolidierungs-Faktor“ wurde bei Microsoft so beantwortet, dass es keinen gäbe. „Häh, wie es gibt keinen?“. Aber im nach hinein glaube ich dem guten Mann sogar.

Stay physical,

j.klein