Anbieter zum Thema
Die Rolle der Treiber
Ein weitere Problem im Zusammenhang sind die Treiber für den para-virtualisierten Betrieb. Kommt als HypervisorKVM zum Einsatz, ist das für Linux-Gäste unproblematisch, weil virtuelleTreiber inzwischen integrale Komponente aller Linux-Versionen sind. Sogar für Windows-Gäste ließen sich virtuelle Treiber theoretisch mit im Image pflegen, weil sowohl das KVM-Team, als auch „Fedora“ die entsprechenden Windows-Gast-KVM-Treiber pflegen, Fedora sogar in digital signierter Form.
Trotzdem dürfen auch diese Informationen in einen Cloud-Setup nicht Teil der VM-Images sei, weil neben KVM ja auch Xen als Hypervisor zum Einsatz komme kann und danke der Mitarbeit von Cloudbase auch Hyper-V. Zum Extrahieren all dieser Informatonen aus einer Windows-Installation, also Linzenz-Key, Hardwareverknüpfugen und spezifische Treiber stellt Microsoft ein Werkzeug mit der Bezeichnung Sysprep zur Verfügung. Dieses können OpenStack-Admins zum Erstellenn derart bereinigter Abbilder nutzen.
Heißt der in einem OpenStack-Szenario verwendete Hypervisor aber nicht KVM, sondern Hyper-V, was zum Beispiel dann Sinn macht, wenn es auf Applikationsseite spezifische Anforderungen an den vorzufindenen Windows-Stack gibt, stellt sich auch für OpenStack-Admin die Frage, ob und wie sich OpenStack und Hyper-V derzeit tatsächlich vertragen. Das wiederum lenkt den Blick auf die Angebote von Cloudbase.it.
Die Compute-Komponente
Die Italiener haben zum Beispiel die OpenStack-Compute-Komponente Nova in Eigenregie auf Windows mit Hyper-V lauffähig gemacht. Das war insofern problemlos möglich, als der Code von OpenStack reines Python ist, das auch unter Windows verfügbar ist.
So lässt sich Nova-Compute inzwischen nicht nur problemlos unter Windows nutzen, Cloudbase hat auch gleich den passenden Windows-Installer entwickelt, mit dem sich ein beliebiger mit Hyper-V ausgerüsteter Host (geht inzwischen ja sogar mit einer Windows-8-Maschine) als Compute-Knoten für Nova verwenden lässt.

(ID:42302304)