Linux-Magazin Clean Linux (Vorschau)

Abbildung 1: Die italienische Firma Cloudbase hat viele der Open-Stack-Komponenten auf Windows portiert.
also alles in bester Ordnung. Aber der
Treiber für den Gast muss speziell darauf
abgestimmt sein, wie der jeweilige Hypervisor
tickt. Ein vorhandener Treiber
zur Paravirtualisierung in KVM hilft in
einem Xen-Setup nicht weiter.
Windows als Gast
Wer Windows als Gast in den unter Linux
verbreiteten KVM-VMs einsetzt – unabhängig
davon, ob von Open Stack oder
einer anderen Virtualisierungsumgebung
gemanagt –, darf das Problem heute als
gelöst betrachten. Die Treiber kommen
zwar nicht direkt von Microsoft, aber
vom KVM-Team. Das Fedora-Repository
[5] bietet sie sogar digital signiert, sodass
sie in allen aktuellen Windows-Ver si onen
problemlos installierbar sind.
Windows-Installationen sind es gewohnt,
eng mit der Hardware verknüpft zu sein,
auf denen sie laufen. In einer Cloudumgebung
geht das aber nur zum Teil, es
gibt schließlich keine Garantie dafür, dass
alle Hypervisor-Knoten auf exakt die gleiche
Hardware setzen. Ganz im Gegenteil:
Je länger die Wolke schon in Betrieb ist,
desto bunter wird der Hardware-Mix.
Und dann sind da ja auch noch streng
rechnerspezifische Details wie der Lizenzschlüssel,
der zu einer virtuellen
Maschine gehört.
Fakt ist: All diese Informationen können
nicht Teil des Windows-Abbilds sein, das
der Cloudadministrator seinen Kunden
zur Verfügung stellt. Das muss im Grunde
ein nacktes Image sein, das keine wie
auch immer gearteten spezifischen Konfigurationsparameter
enthält. Microsoft
stellt für genau dieses Problem eine Lösung
in Form eines Werkzeugs namens
Sysprep [6] bereit.
Mit ihm gelingt es, einem fertig installierten
und konfigurierten Windows quasi
das Gehirn zu entfernen. Das ist ganz
und gar nicht ironisch gemeint: Alles,
was spezifisch für diese eine virtuelle
Maschine war – und dazu gehört auch
der Lizenzschlüssel –, ist nach einem
Sysprep-Aufruf verschwunden, das System
präsentiert sich wieder jungfräulich.
Genau das ist der Moment, in dem der
Admin ein Image zieht und es in den
Open-Stack-Imagestore lädt.
Gigabyte-große Images
Eine Eigenheit im Windows-Kontext fällt
gelegentlich negativ auf: die Größe. Ein
typisches Windows-Image ist ein paar
GByte groß – für Linuxer unfassbar. Das
verursacht beim Starten einer neuen virtuellen
Maschine einige Probleme. Ohne
auf die Hypervisor-abhängigen Unterschiede
eingehen zu wollen, funktioniert
der Start immer gleich: Das Management,
beispielsweise Open Stacks Computing-
Komponente Nova, triggert eine neue
virtuelle Maschine auf einem Hypervisor-
Knoten. Dann lädt der Computing-Knoten
das Image aus dem Speichermanager
Glance lokal auf seine Platte, um im
nächsten Schritt die virtuelle Maschine
von der lokalen Imagekopie zu starten.
Windows-Cloud 09/2013
Sysadmin
www.linux-magazin.de
69
Die Sache mit den Lizenzen
Fernab aller technischer Details lauert auf Unternehmen
noch eine weitere Falle, wenn sie
den Einsatz von Microsoft Windows in einer
Cloud-Computing-Umgebung vorsehen. In einer
Cloud geht es schließlich darum, bei Bedarf in
kurzer Zeit möglichst viele virtuelle Maschinen
starten zu können. Anders als Linux- brauchen
Windows-VMs gewöhnlich einen Lizenzschlüssel.
Eine virtuelle Maschine mit Windows, die
keinen solchen Key hat, funktioniert entweder
gar nicht oder nur als begrenzte Trial-Version,
Dynamische Lizenzen
Die gute Nachricht ist: Es ist über die beschriebenen
Werkzeuge sehr wohl möglich, einer VM
dynamisch einen Lizenzschlüssel mit auf den
Weg zu geben. In Glance, der Imaging-Komponente
von Open Stack, ist dann das Image
wie eine „VM ohne Gedächtnis“ hinterlegt, die
erst im Anschluss an die Eingabe des Lizenzschlüssels
zu einer vollwertigen Instanz mit
dem passenden Featureset aufsteigt.
Pro VM eine Lizenz beantragen?
Die schlechte Nachricht ist: Selbstverständlich
benötigen Admins für jede Windows-VM von
Microsoft eine Lizenz. Als größter Hemmschuh
erweist sich dabei: Die Windows-Volume-Lizenzen,
die viele Unternehmen bereits besitzen,
greifen in solchen Fällen nicht, weil der Hypervisor
bei Cloudumgebungen eben nicht durch
die Firma verwaltet wird, die die Volume-Lizenz
nutzt. Stattdessen verlangt Microsoft von den
Cloudbetreibern, dass sie für jede virtuelle Maschine
eine eigene Lizenz besorgen, die sie
dann allerdings wieder den eigenen Kunden in
Rechnung stellen dürften.
Diese umständliche Vorgehensweise ist de
facto ein großes Ärgernis und bedeutet auch
für Microsoft dringenden Handlungsbedarf.
Die bis jetzt durchgehaltene Strategie, eine
Volume-Lizenz auf Ebene des Hypervisors nur
für solche Server anzubieten, die tatsächlich
unter der Fuchtel des Unternehmens stehen,
funktioniert in einer Cloudumgebung einfach
nicht. Rein technisch spricht ja im Grunde auch
gar nichts dagegen, den Cloudkunden für ihre
VMs die Option einzuräumen, schon vorhandene
Volume-Lizenzen zu nutzen. So drängt sich der
Eindruck auf, dass Microsoft dem Kunden hier
einfach nur in die Tasche greifen will.