Eine komplette Virtualisierungslandschaft auf dem eigenen Laptop – So geht’s
- by Manuel Hossfeld
Eine komplette Virtualisierungslandschaftauf
dem eigenen Laptop – So geht’s
Wenn man sich mit dem
Virtualisierungsprodukt Oracle VM in der aktuellen Version 3.x näher
befassen möchte, bietet es sich natürlich an, eine eigene Umgebung zu Lern- und Testzwecken zu installieren.
Doch leichter gesagt als getan:
Bei näherer Betrachtung der
Architektur wird man schnell feststellen, dass mehrere Rechner
benötigt werden, um überhaupt alle Komponenten abbilden zu können:
Zum einen gilt es, den oder die
OVM Server selbst zu installieren. Das ist recht leicht und schnell
erledigt, aber da Oracle VM ein „Typ 1
Hypervisor ist“ - also direkt auf dem Rechner („bare metal“)
installiert wird – ist der eigenen Arbeits-PC oder Laptop dafür recht ungeeignet. (Eine Dual-Boot Umgebung
wäre zwar denkbar, aber recht unpraktisch.)
Zum anderen wird auch ein Rechner benötigt, auf dem der OVM Manager installiert
wird. Im Gegensatz zum OVM Server erfolgt dessen Installation nicht „bare metal“, sondern auf einem bestehenden Oracle Linux. Aber
was tun, wenn man gerade keinen Linux-Server griffbereit hat und
auch keine extra Hardware dafür opfern will?
Möchte man alle Funktionen von Oracle VM austesten, so sollte man zusätzlich über einen Shared Storag everüfugen. Dieser kann wahlweise über NFS oder über ein SAN (per iSCSI oder FibreChannel) angebunden werden. Zwar braucht man zum Testen nicht zwingend entsprechende „echte“
Storage-Hardware, aber auch die „Simulation“
entsprechender Komponenten erfordert zusätzliche Hardware mit
entsprechendem freien Plattenplatz.(Alternativ können auch fertige „Software Storage Appliances“ wie
z.B. OpenFiler oder FreeNAS verwendet werden).
Angenommen, es stehen tatsächlich keine „echte“ Server- und Storage Hardware
zur Verfügung, so benötigt man für die oben genannten drei Punkte drei bzw. vier Rechner (PCs, Laptops...) - je nachdem ob
man einen oder zwei OVM Server starten möchte.
Erfreulicherweise geht es aber auch mit
deutlich weniger Aufwand:
Wie bereits kurz im Blogpost anlässlich des letzten OVM-Releases 3.1.1 beschrieben, ist die aktuelle Version in der Lage, selbst vollständig innerhalb von
VirtualBox als Gast zu laufen. Wer bei dieser „doppelten
Virtualisierung“ nun an das Prinzip der russischen
Matroschka-Puppen denkt, liegt genau richtig. Oracle VM VirtualBox
stellt dabei gewissermaßen die äußere Hülle dar – und da es
sich bei VirtualBox im Gegensatz zu Oracle VM Server um einen „Typ
2 Hypervisor“ handelt, funktioniert dieser Ansatz auch auf einem
„normalen“ Arbeits-PC bzw. Laptop, ohne dessen eigentliche
Betriebsystem komplett zu überschreiben.
Doch das beste dabei ist: Die Installation der jeweiligen VirtualBox VMs
muss man nicht selber durchführen. Der OVM Manager als auch der OVM Server stehen bereits
als vorgefertigte „VirtualBox Appliances“ im Oracle Technology
Network zum Download zur Verfügung und müssen im Grunde nur noch importiert und konfiguriert werden.
Das folgende
Schaubild verdeutlicht das Prinzip:
Die dunkelgrünen Bereiche stellen
jeweils Instanzen der eben erwähnten VirtualBox Appliances für OVM
Server und OVM Manager dar. (Hier im Bild sind zwei OVM Server zu
sehen, als Minimum würde natürlich auch einer genügen. Dann können aber viele Features wie z.B. OVM HA nicht ausprobieren werden.)
Als cleveren Trick zur Einsparung einer
weiteren VM für Storage-Zwecke hat Wim Coekaerts (Senior Vice
President of Linux and Virtualization Engineering bei Oracle), der
„Erbauer“ der VirtualBox Appliances, die OVM Manager Appliance
bereits so vorbereitet, dass diese gleichzeitig als NFS-Share (oder
ggf. sogar als iSCSI Target) dienen kann. Dies beschreibt er auch
kurz auf seinem Blog.
Die hellgrünen Ovale stellen die VMs
dar, welche dann innerhalb einer der virtualisierten OVM Server
laufen können. Aufgrund der Tatsache, dass durch diese „doppelte
Virtualisierung“ die Fähigkeit zur Hardware-Virtualisierung
verloren geht, können diese „Nutz-VMs“ demzufolge nur
paravirtualisiert sein (PVM).
Die hier in blau eingezeichneten
Netzwerk-Schnittstellen sind virtuelle Interfaces, welche beliebig
innerhalb von VirtualBox eingerichtet werden können. Wer die
verschiedenen Netzwerk-Rollen innerhalb von Oracle VM im Detail
ausprobieren will, kann hier natürlich auch mehr als zwei dieser
Interfaces konfigurieren.
Die Vorteile dieser Lösung für Test-
und Demozwecke liegen auf der Hand: Mit lediglich einem PC bzw.
Laptop auf dem VirtualBox installiert ist, können alle oben genannten
Komponenten installiert und genutzt werden – genügend RAM
vorausgesetzt. Als Minimum darf hier 8GB gelten. Soll auf der
„Host-Umgebung“ (also dem PC auf dem VirtualBox läuft) nebenbei
noch gearbeiten werden und/oder mehrere „Nutz-VMs“ in dieser
simulierten OVM-Server-Umgebung laufen, empfehlen sich
natürlich eher 16GB oder mehr.
Da die
nötigen Schritte zum Installieren und initialen Konfigurieren der
Umgebung ausführlich in einem entsprechenden Paper beschrieben sind, möchte ich im Rest dieses Artikels noch einige zusätzliche Tipps
und Details erwähnen, welche einem das Leben etwas leichter machen
können:
Um möglichst entstpannt und mit
zusätzlichen „Sicherheitsnetz“ an die Konfiguration der
Umgebung herangehen zu können, empfiehlt es sich, ausgiebigen
Gebrauch von der in VirtualBox eingebauten Funktionalität der VM
Snapshots zu machen. Dies ermöglicht nicht nur ein Zurücksetzen
falls einmal etwas schiefgehen sollte, sondern auch ein beliebiges
Wiederholen von bereits absolvierten Teilschritten (z.B. um eine
andere Idee oder Variante der Umgebung auszuprobieren).
Sowohl bei den gerade erwähnten
Snapshots als auch bei den VMs selbst sollte man aussagekräftige
Namen verwenden. So ist sichergestellt, dass man nicht durcheinander kommt und auch nach
ein paar Wochen noch weiß, welche Umgebung man da eigentlich vor sich hat. Dies
beinhaltet auch die genaue Versions- und Buildnr. des jeweiligen
OVM-Releases. (Siehe dazu auch folgenden Screenshot.) Weitere
Informationen und Details zum aktuellen Zustand sowie Zweck der
jeweiligen VMs kann in dem oft übersehenen Beschreibungsfeld
hinterlegt werden.
Es empfiehlt sich, bereits
VOR der Installation einen Notizzettel (oder eine Textdatei) mit den
geplanten IP-Adressen und Namen für die VMs zu erstellen. (Nicht
vergessen: Auch der Server Pool benötigt eine eigene IP.) Dabei
sollte man auch nochmal die tatsächlichen Netzwerke der zu
verwendenden Virtualbox-Interfaces prüfen und notieren.
Achtung: Es gibt im Rahmen der
Installation einige Passworte, die vom Nutzer gesetzt werden können
– und solche, die zunächst fest eingestellt sind. Zu letzterem
gehört das Passwort für den ovs-agent sowie den root-User auf den
OVM Servern, welche beide per Default „ovsroot“ lauten. (Alle
weiteren Passwort-Informationen sind in dem „Read me first“
Dokument zu finden, welches auf dem Desktop der OVM Manager VM
liegt.)
Aufpassen muss man ggf. auch in
der initialen „Interview-Phase“ welche die VirtualBox VMs
durchlaufen, nachdem sie das erste mal gebootet werden. Zu diesem
Zeitpunkt ist nämlich auf jeden Fall noch die amerikanische
Tastaturbelegung aktiv, so dass man z.B. besser kein „y“ und „z“
in seinem selbst gewählten Passwort verwendet.
Aufgrund der Tatsache, dass wie
oben erwähnt der OVM Manager auch gleichzeitig den Shared Storage
bereitstellt, sollte darauf geachtet werden, dass dessen VM vor den OVM
Server VMs gestartet wird. (Andernfalls „findet“ der dem OVM
Server Pool zugrundeliegende Cluster sein sog. „Server Pool File
System“ nicht.)
