Eigentlich wäre ich ja ganz glücklich mit KVM/libvirt. Es ist stabil, es kostet nix, es ist leistungsfähig. Aber wenn ich mir vorstelle, daß ich das morgen in einem nicht ganz kleinen Unternehmen würde einführen müssen, dann fehlen mir da einfach noch ein paar Features. Jetzt kann es natürlich sein, daß man das alles ohne Probleme nachbilden kann - in dem Fall freue ich mich natürlich über Feedback.

1. Unterstützung für Gruppen von Gästen

Man stelle sich vor, zwei Abteilungen - nennen wir sie mal NAS und DS, die werden uns in diesem Artikel noch öfter begegnen - teilen sich zwei Virtualisierungs-Server. Die Jungs von NAS wollen jetzt irgendwas mit Routing testen und erstellen sich 5 virtuelle Maschinen, um da Quagga laufen zu lassen. DS spielt gleichzeitig auf dem selben Knoten ein Upgrade ihrer Oracle RACs auf 11gR2 durch und verursacht soviel Last, daß die Jungs von NAS total verärgert sind. Einer von beiden muß jetzt seine Maschinen umziehen. Und genau da wird es problematisch: Beide Seiten müssten im Prinzip für jede Maschine einzeln den Migrationsbefehl erteilen (und ja, mir ist klar, daß das in einer Schleife erfolgen kann). Was man aber eigentlich will ist ein Möglichkeit, eine Gruppe von Rechnern zu definieren und diese gleichzeitig zu migrieren. Sprich, alle werden gleichzeitig auf Knoten A eingefroren, die State-Information von allen wird gleichzeitig auf Knoten B übertragen und sie werden dort auch wieder zur gleichen Zeit gestartet.


2. Unterstützung für ACLs auf virtuelle Maschinen

Jetzt nicht falsch verstehen - mir ist klar, daß man den Zugriff via VCN auf schon laufende Maschinen einschränken kann. Mir geht es hier aber eher um den Zugriff auf die virtuellen Maschinen selbst mit den üblichen Verwaltungstools: Obiges Beispiel nochmal angenommen: Die Leute in der Abteilung NAS sollten einfach keinen Zugriff auf die Server von DS haben - und umgekehrt natürlich genauso. Die Erfahrung zeigt nämlich, daß früher oder später die Kommunikation mal nicht funktioniert und man dann den Kollegen genau die eine virtuelle Maschine killt, die jene in einem Dauerlauf-Test hatten. Und danach ist dann das Geschrei groß.


3. Abhängigkeiten und Prioritäten von VMs

Angenommen ich virtualisiere mehr als nur meine persönliche Testbüchse - dann wird früher oder später der Moment kommen, an dem eben nicht mehr alle Gäste gleich sind: Plötzlich ist es mir dann wichtig, daß z.B. nach einem Neustart des KVM-Hosts zuerst meine LDAP- und DNS-Server starten, danach der virtuelle iSCSI-Server und erst zuletzt die beiden RAC-Knoten. Momentan kann ich sowas nicht abbilden - es sei denn, ich lege über KVM/libvirt noch ein weiteres Framework, z.B. einen Cluster-Manager wie Pacemaker.


4. Fehlertoleranz

Wenn ich irgendwann an dem Punkt angelangt bin, daß ich wichtige Server virtualisiere, und zwar solche, für die ich nicht mit einfachen Möglichkeiten (z.B. einmal Cisco ACE davorsetzen) Fehlertoleranz schaffen kann, dann will ich eigentlich, daß so ein Server zweimal läuft: Einmal aktiv auf dem KVM-Knoten A und einmal als Schattenkopie, bei der der interne State stets aktuell gehalten wird, auf dem Knoten B. Fällt der Knoten A aus, dann soll Knoten B die Maschine sofort aktiv schalten und eine weitere Schattenkopie von sich selbst erzeugen (vorzugsweise natürlich auf einem Host, der noch läuft). Während man das übernehmen noch mit einem Cluster-Manager wie Pacemaker nachbilden kann, so funktioniert das mit der Schattenkopie derzeit einfach noch nicht, soweit ich weiß - das ist aber ein Feature, auf das ich im Unternehmensumfeld nicht verzichten kann und will.


5. Lastverteilung

Zu guter Letzt - und hier kehren wir zum ersten Punkt zurück - fehlt mir bei KVM momentan noch die automatische Lastverteilung. Wenn libvirt in der Lage wäre, Ressourcen-Engpässe der Wirtsysteme automatisch zu erkennen und zu reagieren, in dem es z.B. eine ganze Gruppe von Hosts verschiebt, dann wären sich im ersten Beispiel DS und NAS auch nicht in die Quere gekommen. Nachbilden kann man sowas wiederum nur über ein externes Framework, z.B. eben Pacemaker (BTDT, sucks).



Wie gesagt: Ich lasse mich gerne eine besseren belehren, wenn die Punkte, die ich hier angesprochen habe, entweder in der Realität keine echten Probleme oder schon längst gelöst sind.