Das Verschachteln von Hypervisoren ineinander, bekannt als Nested Virtualization, erlaubt das Einrichten eines kompletten Virtualisierungsszenarios mit Datacenter, Storage und HA-Funktionen auf einem Notebook. Dieser Artikel zeigt, wie das mit Linux-I-SCSI und den kostenlosen Trials von VMware gelingt.

Manch modernes Notebook birgt Hardware, die noch vor wenigen Jahren auch ausgewachsenen Servern gut gestanden hätte: 64-Bit-CPU, als Dual- oder Quadcore, 8 GByte RAM und 500-GByte-Festplatte. Einfache Desktop- oder Office-Anwendungen schaffen solche Geräte mit links, nur spezielle Einsatzgebiete wie die Software-Entwicklung, zum Beispiel mit einem J2EE-Applicationserver nebst IDE, oder das Bearbeiten von HD-Videos lasten 8 GByte RAM aus.

Unter Admins und Consultants zunehmend verbreitet ist das Bedürfnis, auch komplexe Demo-Installationen von Storage- und Virtualisierungsszenarien mit zum Kunden nehmen zu können. Statt im Labor ausgewachsene Server aufzusetzen und die Kunden einzubestellen, lässt sich das Labor mit den eigenen Cloudprodukten gewissermaßen in die Laptoptasche verlagern.

Dieser Artikel zeigt, wie sich mit verschachtelten Virtualisierungsebenen (Nested Virtualization) ein komplettes VMware-Vsphere-Setup mit Shared-I-SCSI-Storage simulieren lässt, um etwa im Kundengespräch die Vorzüge einer Virtualisierungsplattform auf dem mitgebrachten Notebook anschaulich zu demonstrieren.

Als Nest für diesen Artikel dient ein beliebiges Marken-Notebook mit Core-i7-Dualcore-CPU (mit Hyperthreading vier Cores), 8 GByte RAM und 500 GByte Platz auf der Festplatte. Das Szenario ist mit jedem ähnlich ausgestatteten System möglich, solange die verbaute CPU die Virtualisierungstechniken Intel-VT oder AMD-V mitbringt. Auch Virtualbox, Xen oder KVM können theoretisch als Basis dienen, verfügen aber an vielen Stellen (noch) nicht über die gleichen Funktionen wie Marktführer VMware.

Leistungsfähiges Nest

Für das anvisierte Vsphere-Demosetup sind folgende virtuellen Maschinen (VMs) geplant:

• Ein VMware ESXi 4.1
• Ein VMware ESXi 5.0
• Eine-Vcenter-Server-Appliance
• Ein Vsphere-Client auf Windows XP
• Ein I-SCSI-Target Fedora 17

All diese Systeme landen auf dem oben erwähnten Notebook, dessen eigentliches Betriebssystem durchaus weiter als tagtägliches Arbeitsgerät dienen kann. Das Testgerät selbst betreibt Fedora 16, als oberste Virtualisierungsplattform kommt darauf der frei erhältliche VMware Player zum Einsatz, weil der, neben VMware Workstation und ESX selbst, der einzige Hypervisor ist, auf dem sich ein ESX virtualisieren lässt.

Mit dem Setup auf Basis von KVM ließe sich zwar noch der Overhead des Hosted Hypervisors sparen, aber sämtliche Versuche, einen ESX zur Mitarbeit als Gast unter KVM zu bewegen, sind derzeit leider nicht erfolgreich.

Magisch verschachtelt

Das Zauberwort, um überhaupt einen Hypervisor zu virtualisieren und darin dann wiederum weitere Gäste zu betreiben, heißt Nested Virtualization. Dabei reicht das System recht trickreich die Virtualisierungsfunktionen der CPU zum Gast durch. Für die Extensions von AMD, die Secure Virtual Machine (SVM), klappt dies bei KVM dank der Arbeit von Alexander Graf und Jörg Rödel seit Kernel 2.6.30 [1]. Bei Intels Virtual Machine Extensions (VMX) beschreibt ein ausführliches Whitepaper aus IBMs Labor, wie die dortigen Ingenieure diese für KVM nachgerüstet haben [2].

Diese Funktionen sind zwar noch als experimentell gekennzeichnet, bei den Kerneln aktueller Distributionen aber meist dennoch einkompiliert und aktiviert. Wer das schon jetzt testen will, lädt einfach die Module »kvm-amd« oder »kvm-intel« mit der Option »nested=1« . Allerdings muss für 64-Bit-Gäste bei KVM der Host ebenfalls mit einem 64-Bit-Kernel laufen – bei VMware Player/Workstation sowie Virtualbox laufen 64-Bit-Gäste auch auf einem 32-Bit-Hostsystem.

Als Gastgeber auf dem Notebook kann jede beliebige Distribution dienen – auch Windows. Der VMware Player (aktuell ist Version 4.0.3) bringt zwar eine ganze Reihe vorkompilierter Kernelmodule mit, aber leider keine passenden für den inzwischen auf Version 3.3.4 aktualisierten Kernel des im Demosetup verwendeten Fedora 16. Das Kompilieren der VMware-Module ist bekanntermaßen bei aktuellen Kerneln etwas problematisch, gelingt aber mit den Hinweisen [3] und Patches von einschlägigen Seiten [4].

Erster Gast: I-SCSI-Storage

Der erste Gast im System wird das I-SCSI-Target, das als Storage dient. Wer sich hier Arbeit sparen will, nimmt dafür das vorbereitete Image von der DELUG-DVD und springt im Artikel zur Konfiguration der anderen Gäste. Der Linux-Kernel bringt seit geraumer Zeit das Multiprotocol Storage Target von http://linux-iscsi.org (LIO) mit, das seit Kernel 3.1 auch das I-SCSI-Protokoll beherrscht. Daher reicht auch für das Target eine Distribution mit halbwegs aktuellem Kernel.

Wer das eigentliche I-SCSI-Target nicht von Hand über die Config-FS-Schnittstelle konfigurieren will, nutzt das Kommandozeilen-Werkzeug »targetcli« [5], das auch einen interaktiven Modus kennt. Dank Tab-Completion lässt sich das recht komfortabel bedienen, wobei es sich deutlich an das ursprüngliche »rtsadmin« anlehnt [6]. Targetcli ist ab Fedora 16 sowie bei den Debian-Versionen Weezy und Sid enthalten. Wer bereits eine fertige VM mit einer dieser Distributionen hat, kann sie für das benötigte Target verwenden.

Fedora 17

Für das I-SCSI-Setup entschied sich der Autor, kurzerhand eine minimale Installation der Vorabversion von Fedora 17 (64 Bit) aufzusetzen (auf der DELUG-DVD), die bis zum Erscheinen dieses Hefts den finalen Stand erreicht haben dürfte.

Die VM braucht neben den initialen 512 MByte RAM und einer Netzwerkkarte nur noch zwei Disks – die erste für die Betriebssystem-Installation an sich, die zweite wird später als I-SCSI-Target exportiert. Die Netzwerkkarte kann der Admin sowohl im NAT- als auch im Bridged-Modus betreiben, je nachdem, ob das Demosetup nur lokal auf dem Notebook selbst oder auch von außen erreichbar sein soll.

Doch empfiehlt sich im NAT-Modus die Konfiguration statischer IPs statt der praktischen DHCP-Adressenvergabe, damit im späteren Betrieb mit allen VMs die für die I-SCSI-Verbindung wichtigen IP-Adressen nicht durcheinandergeraten. VMwares DHCP-Dienst teilt in der Regel die Adressen aus der oberen Hälfte des letzten Oktetts zu, sodass man für die statischen Adressen die untere Hälfte verwenden kann. In diesem Fall sind das die Adressen aus dem Bereich von 192.168.124.3 bis 192.168.124.127, Nameserver und Default-Gateway sind standardmäßig unter 192.168.124.2 zu finden.

Im laufenden Gast kann der Admin jetzt den ersten Teil des I-SCSI-Targets konfigurieren, für die endgültigen Einstellungen braucht er später die I-SCSI-Initiator-Namen der beiden ESX-Hosts. Diese erhält er erst nach der Installation der ESX-Gäste. Das Target exportiert die zweite Disk »sdb« des Gastes. Dazu definiert der Admin zunächst »/dev/sdb« als blockbasierten Backstore und legt anschließend ein I-SCSI-Target mit einem frei gewählten Namen und diesem Backstore an, das sich an beliebige IP-Adressen bindet (Listing 1).

01 # targetcli
02 /> cd /backstores/block
03 /backstores/block> create myblock1 /dev/sdb
04 /backstores/block/myblock1> cd /iscsi
05 /iscsi> create iqn.2003-01.org.linux-iscsi.fedora17.x8664:sn.b27d726e249b
06 /iscsi/iqn.20...726e249b/tpg1> cd luns
07 /iscsi/iqn.20...49b/tpg1/luns> create /backstores/block/myblock1
08 /iscsi/iqn.20...pg1/luns/lun0> cd ../../portals
09 /iscsi/iqn.20.../tpg1/portals> create 0.0.0.0
10 /iscsi/iqn.20.../0.0.0.0:3260> cd ../..
11 /iscsi/iqn.20...726e249b/tpg1> set attribute authentication=0

Der Befehl »set attribute authentication=0« in Zeile 11 schaltet die Authentisierung für das Target komplett ab. Diese ist für das Demosetup nicht nötig, weil einfache ACLs für die I-SCSI-Initiatoren des ESX völlig ausreichen.

VMware-Trials

Als Nächstes kommen die Gäste für die beiden ESX-Hosts und den Vcenter Server an die Reihe. Die Installationsdateien in Form von ISO-Images gibt es zum Download auf VMwares Website, sowohl für ESXi 4.1 [7] als auch ESXi 5.0 [8]. Ebenso findet sich dort eine virtuelle Appliance nebst fertig konfiguriertem Vcenter Server 5.0 mit dem passenden Vsphere-Client 5.0 [9]. Die ISO-Images für den ESX und den Vsphere-Client fallen mit je 300 bis knapp 400 MByte moderat aus. Die Appliance des Vcenter Server kommt in Form einer OVF (Open Virtualization Format) sowie zweier VMDK-Dateien, die zusammen mit gut 4 GByte zu Buche schlagen. Sowohl die beiden ESX als auch der Vcenter Server arbeiten mit einer Testlizenz, die nach Installation 60 Tage gültig ist.

Hypervisoren zu Gast

Als nächster Gast erscheint ein ESXi 4.1 im Nest. Damit der im VMware Player funktioniert, bedarf es spezieller Konfigurationsparameter. Glücklicherweise erkennt der Wizard das ESX-ISO-Image und richtet die neue VM passend ein und schlägt bereits den richtigen Typ des Gastsystems (Abbildung 1) vor.

Abbildung 1: Nachträglich geht das nicht mehr: Den Typ des Gast-OS (»VMware ESX«) muss der Admin dem ISO-Image schon im Wizard mitgeben.

Die weiteren Vorschläge des Wizards kann der Admin getrost übernehmen, nur bei der virtuellen HDD reichen statt der vorgeschlagenen 40 auch 6 GByte absolut aus – der ESX muss ja seine Gäste später nicht auf der lokalen Disk ablegen, dafür bekommt er den Shared-I-SCSI-Storage. Die empfohlenen 2 GByte RAM sowie die zwei virtuellen CPUs sind aber für den Betrieb des ESX notwendig, und der Modus der Netzwerkkarte will analog zu der des I-SCSI-Targets konfiguriert sein.

Als letzten Schritt startet der Wizard den Gast – und die Installation des ESX beginnt. Auch der Installer lässt sich unkompliziert durcharbeiten und stellt bis zum Abschluss nur wenige Fragen. Doch beklagt sich VMware Player manchmal beim Initialisieren des Netzwerkkartentreibers im Kernel des ESX, dass es den virtuellen Ethernet-Adapater nicht in den Promiscuous Mode schalten könne, was für den Betrieb der Nested VMs im virtualisierten ESX später aber sinnvoll ist. Ein Eintrag in VMwares Knowledge Base beschreibt einen Workaround für dieses Problem [10].

Nach dem Reboot startet der ESX und wartet auf seine Konfiguration. Da diese später über den Vcenter Server erfolgen soll, ist hier zunächst nur die Anpassung der IP-Adresse auf einen statischen Wert notwendig. Der ESX startet in der Default-Konfiguration mit einer Adresse aus dem DHCP-Pool. Aber die Taste [F2] und das anschließende Login als »root« (mit leerem Passwort) führen zur Konfiguration mit den Menüpunkten »Configure Management Network« und »IP Configuration« . Im Beispiel bekommt dieser ESX die Adresse 192.168.124.11 (Abbildung 2). Beim Verlassen des Menüs mit [Esc] sollte der Admin die Frage nach dem Restart des Management-Netzwerks mit »yes« beantworten.

Abbildung 2: Standardmäßig nutzt der ESX eine über DHCP verteilte IP, in den Netzwerkeinstellungen lässt sich das ändern.

Wer kein US-Keyboard-Layout will, stellt dies unter »Configure Keyboard« um, wer sich auf der Kommandozeile des ESX umsehen möchte, findet hinter dem Menü »Troubleshooting Options« den Punkt »Enable Remote Tech Support (SSH)« , um den SSH-Daemon einzuschalten.

Der Nächste: ESXi 5.0

Weiter geht’s mit dem zweiten Gast, jetzt einem ESXi 5.0. Auch hier lädt der Admin im Wizard wieder das ISO-Image für die Installation, sodass dieser die VM vorbereitet – 6 GByte für die HDD sind auch hier genug. Der Bootscreen des ESXi 5 sieht etwas anders aus, die Installation verläuft aber ähnlich zu der des ESXi 4.1 – nur fragt der Installer diesmal gleich nach dem Keyboard-Layout und einem Passwort für den Root-User.

Allerdings verwirrt der Installer mit einer Warnmeldung, die Hardwarevirtualisierung der CPU wäre nicht verfügbar. Nested VMs starten später aber trotzdem problemlos. Hier fehlt nur noch ein Reboot nach erfolgreicher Installation, dann ist wieder die Netzwerkkonfiguration auf eine statische IP-Adresse anzupassen, diesmal die 192.168.124.12 – fertig.

Noch ein Schwergewicht

Ist das Demo-Notebook nur mit 4 oder 6 GByte RAM ausgestattet, dann geht jetzt bereits der Hauptspeicher zur Neige. Ein weiteres kleines System, etwa eine Windows-XP-VM mit installiertem Vsphere-Client, erlaubt es jetzt, die beiden ESX-Hosts zu verwalten. Allerdings fehlen dann, trotz möglichem Shared Storage, so interessante Features wie Clustering oder Vmotion, mit denen sich gerade bei Vorführungen beim Kunden so richtig punkten lässt.

Deshalb braucht es noch einen Vcenter Server. Diesen gibt es ebenfalls als nahezu fertig konfigurierte virtuelle Appliance von VMware zum Download. Deren OVF-Datei ist mit 8 GByte RAM vorkonfiguriert – 4 reichen aber locker aus, weniger sollten es allerdings nicht sein, denn die Appliance auf Basis von SLES 11 bringt neben allerlei Webapps in einem Java-App-Server, einem LDAP-Server und diversen VMware-Agents auch noch eine ausgewachsene DB2-Datenbank als embedded Datastore mit.

Das Öffnen der OVF-Datei im VMware Player importiert die Appliance automatisch, was bei den 4 GByte großen VMDK-Dateien ein wenig dauert. Jetzt gilt es, den Hauptspeicher auf 4 GByte zu reduzieren und je nach Konfiguration der anderen I-SCSI- und ESX-Gäste den Netzwerkadapter auf NAT umzustellen. Die Appliance richtet beim ersten Start einige Services ein und aktiviert das Netzwerk mit DHCP. Ein Welcome-Screen zeigt die Schritte für die abschließende Grundkonfiguration von Vcenter Server. Über ein kleines Auswahlmenü lässt sich hier das Netzwerk anpassen, auch diese Appliance soll eine statische IP-Adresse erhalten: 192.168.124.13.

Jetzt fehlt noch die Grundkonfiguration unter der URL »https://192.168.124.13:5480« . Hierzu meldet sich der Admin als User »root« mit dem Passwort »vmware« auf dem Web-GUI an. Zunächst muss er auf dem ersten Reiter die EULA akzeptieren und kann dann unter »Database« den Typ von »UNCONFIGURED« auf »embedded« umstellen, um die DB2 zu aktivieren. Mit einem Klick auf »Save Settings« legt er das Repository des Datastore in der eingebetteten DB2-Datenbank an, ein Klick auf »Test Settings« überprüft, ob alles geklappt hat (Abbildung 3).

Abbildung 3: Hat alles richtig geklappt, zeigt das Web-GUI »Operation was successful« an.

Jetzt muss der Admin den Vcenter Server nur noch im Reiter »Status« über den Button »Start vCenter« starten. Nach kurzer Wartezeit liefert das Web-GUI den Service-Status »Running« . Wer möchte, kann über die weiteren Reiter noch andere Konfigurationen vornehmen, wobei außer der Zeitzone für das Demosetup kein Bedarf besteht. Alles Weitere erledigt später der Vsphere-Client.

Der letzte Gast

Für den Vsphere-Client komplettiert der Admin die Gästeliste mit einer Windows-VM. ISO-Images für eine beschränkte Laufzeit gibt es dafür bei Microsoft, etwa für Windows 7 und 8, aber auch Windows Server. Prinzipiell ist jedes Windows ab XP geeignet, wobei letzteres am wenigsten Ressourcen benötigt.

Ausgestattet mit 512 MByte RAM und der per NAT übersetzten statischen IP-Adresse 192.168.124.14 landet die Software des zuvor heruntergeladenen Vsphere-Clients auf dem proprietären Betriebssystem. Sofern noch nicht vorhanden zieht dessen Setup noch Dotnet nach. Nach einem Reboot des Windows-Gastes ist der Client bereit zum ersten Login auf den Vcenter Server unter der Adresse 192.168.124.13. Die Login-Daten sind die gleichen wie an der Konsole der Appliance, also »root« und »vmware« .

Da der Vcenter Server für die verschlüsselte Kommunikation ein selbst signiertes Zertifikat verwendet, spuckt der Vsphere-Client zunächst eine Warnung aus. Mit einem Klick auf »Ignorieren« überredet der Admin den Client zur Mitarbeit und speichert das Zertifikat mit einem Häkchen dauerhaft.

Vsphere: Cluster-Setup

Damit im Demosetup auch Clustering und Livemigration funktionieren, ist ein Datacenter erforderlich. Darin bedarf es eines Clusters mit den beiden ESX-Hosts sowie eines Datastore, der an beide ESX angebunden ist. Zunächst erstellt der Admin dazu im Inventory das Datacenter »myData« .

Mit einem Rechtsklick auf das neue Datacenter lässt sich ein neuer Cluster »myCluster« mit einem Wizard konfigurieren. Der Admin aktiviert die Option »vSphere HA« , damit er auch die Failover-Funktionen demonstrieren kann. Die Option »vSphere DRS« (Distributed Resource Scheduling) dagegen ist auf dem Demo-Notebook nicht sinnvoll.

Im Cluster fügt er jetzt noch mit wenigen Rechtsklicks die beiden virtualisierten ESX-Hosts mit ihren IP-Adressen hinzu, ebenfalls über einen Wizard. Der Benutzername ist »root« mit leerem Passwort oder dem bei der Installation gesetzten Passwort (ESXi 5.0). Der Admin akzeptiert den Fingerprint und belässt es ansonsten bei den Vorgabewerten des Wizards, auch bezüglich der vorgeschlagenen Testlizenz.

Alle Aktionen im Vsphere-Client landen in einer Warteschlange auf dem Vcenter Server, daher dauert es einen Moment, bis die Konfigurationen aktiv sind. Der Fortschritt bei den einzelnen Aktionen lässt sich im unteren Abschnitt des Clients verfolgen.

Nestwechsel

Damit die Livemigration einer VM von einem ESX-Host auf den anderen klappt, muss der Admin die Option »vMotion« auf den Netzwerkadaptern der ESX aktivieren. Dazu schaltet er sie beim Konfigurieren der beiden ESX-Hosts in den Eigenschaften des Standardswitch »vSwitch0« unter »Netzwerk« frei.

Ein gelbes Ausrufezeichen am Icon der beiden ESX signalisiert eine oder mehrere Warnungen, beispielsweise wenn beiden ESX noch ein Datastore fehlt. Um diesen einzurichten, muss der Admin das I-SCSI-Target anbinden. Dessen Konfiguration verlangt nach den ACLs mit den Namen der Software-Initiatoren der Clients. In der Reiterkarte »Konfiguration« der beiden ESX-Hosts fügt er unter »Speicheradapter« mit einem Klick auf »Hinzufügen« als Erstes »Software-iSCSI-Adapter« hinzu, dessen zufällig generierter I-SCSI-Name anschließend im unteren Bereich »Details« auftaucht.

Mit den I-SCSI-Namen der beiden ESX-Hosts lässt sich nun im I-SCSI-Target je eine ACL anlegen, die die vorhandene Disk aus dem Backstore als LUN an das ESX mappt. Das erledigt wiederum »targetcli« im Gast für das Target (Listing 2). Die Konfiguration des I-SCSI-Targets sollte jetzt – gegebenenfalls mit abweichenden Target- und ACL-Bezeichnungen – ähnlich wie in Listing 3 aussehen:

01 # targetcli
02 /> cd iscsi/iqn.2003-01.org.linux-iscsi.fedora17.x8664:sn.b27d726e249b/tpg1/acls
03 /iscsi/iqn.20...49b/tpg1/acls> create iqn.1998-01.com.vmware:localhost-1c43ed63
04 /iscsi/iqn.20...host-1c43ed63> cd ..
05 /iscsi/iqn.20...49b/tpg1/acls> create iqn.1998-01.com.vmware:localhost-1a027628
06 /iscsi/iqn.20...host-1a027628> cd /
07 /> saveconfig

01 # targetcli
02 /> ls
03 o- / .......................................................................................... [...]
04   o- backstores ............................................................................... [...]
05   | o- block ..................................................................... [1 Storage Object]
06   | | o- myblock1 ...............................................................[/dev/sdb activated]
07   | o- fileio .................................................................... [0 Storage Object]
08   | o- pscsi ..................................................................... [0 Storage Object]
09   | o- ramdisk ................................................................... [0 Storage Object]
10   o- ib_srpt ............................................................................ [Not found]
11   o- iscsi ............................................................................... [1 Target]
12   | o- iqn.2003-01.org.linux-iscsi.fedora17.x8664:sn.b27d726e249b ........................... [1 TPG]
13   |   o- tpg1 ............................................................................. [enabled]
14   |     o- acls ............................................................................ [2 ACLs]
15   |     | o- iqn.1998-01.com.vmware:localhost-1a027628 ............................... [1 Mapped LUN]
16   |     | | o- mapped_lun0 ............................................... [lun0 block/myblock1 (rw)]
17   |     | o- iqn.1998-01.com.vmware:localhost-1c43ed63 ............................... [1 Mapped LUN]
18   |     |   o- mapped_lun0 ............................................... [lun0 block/myblock1 (rw)]
19   |     o- luns ............................................................................. [1 LUN]
20   |     | o- lun0 ....................................................... [block/myblock1 (/dev/sdb)]
21   |     o- portals ....................................................................... [1 Portal]
22   |       o- 0.0.0.0:3260 ...................................................................... [OK]
23   o- loopback ............................................................................ [0 Target]
24   o- qla2xxx ............................................................................ [Not found]
25   o- tcm_fc ............................................................................. [Not found]

Die LUNs bekannt geben

Nun gibt der Admin die LUNs den beiden ESX bekannt: In der Reiterkarte »Konfiguration« unter »Speicheradapter« und dem ausgewähltem I-SCSI-Adapter erledigt das ein Klick auf »Eigenschaften« im Bereich »Details« und dort das Eingeben der Daten. Bei ESXi 4.1 fügt er in den Eigenschaften im Reiter »Dynamische Erkennung« den Server mit der IP-Adresse 192.168.124.10 hinzu, beim ESXi 5.0 bedarf es in den Eigenschaften des Adapters zuvor – im Reiter »Netzwerkkonfiguration« – noch einer Bindung an den Ethernet-Adapter der VM.

Die folgende Abfrage, ob das System den Adapter erneut prüfen soll, wird mit »Ja« beantwortet. Daraufhin sollte im Punkt »Speicher« und der Geräte-Ansicht neben dem lokalen HDD und CD-ROM des virtuellen ESX auch die I-SCSI-LUN erscheinen (Abbildung 4).

Abbildung 4: Der Vsphere-Client listet die erfolgreich angebundenen LUNs aus dem I-SCSI-Target.

Jetzt fehlt noch der gemeinsame Datastore. VMware hat mit ESXi 5 das neue Format VMFS-5 eingeführt, das jedoch nicht abwärtskompatibel ist. Da das Demosetup auch einen ESXi 4.1 enthält, muss, falls der Datastore über den ESXi 5 angelegt ist, unbedingt das VMFS-3-Format Verwendung finden. Nach dem Klick auf »Speicher hinzufügen« in der Rubrik »Speicher« (und der Ansicht auf die Datenspeicher) leitet ein Wizard durch das Anlegen des Storage. Als Typ dient »Festplatte/LUN« und anschließend die »LIO-ORG iSCSI Disk« .

Der Datastore erhält den Namen »myStore« , die restlichen Parameter lassen sich einfach abnicken. Bereits jetzt informiert der Vcenter Server den zweiten ESX automatisch und sucht nach neuen Datastores. Wird er dabei nicht fündig, hilft ein Klick auf »Alles erneut prüfen« , was die Suche manuell anstößt.

Cluster-Datastore aufbauen

Die Cluster-Funktionalitäten verlangen aber auch, den neuen Datastore zu einem Cluster-Datastore umzuwidmen. Dazu stellt der Admin in der Navigationsleiste des Vsphere-Clients die Ansicht um auf »Bestandsliste | Datenspeicher und Datenspeicher-Cluster« (Hotkey: [Strg]+[Shift]+[D]). Ein Rechtsklick auf das Datacenter »myData« erlaubt es, einen neuen Datenspeicher-Cluster namens »myCluStore« anzulegen. Bei den Hosts und Clustern wählt der Admin »myCluster« und im nächsten Schritt den Datastore »myStore« . Nach Abschluss des Wizard ist der Cluster komplett und die Ansicht lässt sich wieder auf Hosts und Cluster zurückstellen: [Strg]+[Shift]+[H]. Das Szenario ist damit vollständig, jetzt kann es der Admin testen.

Kuckuck: Zu Gast beim Gast

Ob ein Nested Guest im virtualisierten Datacenter läuft, zeigt sich schnell: Ein Live-Linux, das von einem ISO-Image startet, eignet sich dafür am besten. Der Admin importiert es in den Cluster-Datastore, wonach es für beide ESX-Hosts bereitsteht. Dazu klickt er mit der rechten Maustaste in der Konfiguration eines ESX im Punkt »Speicher« auf »Datenspeicher« und den Datastore »myStore« und wählt »Datenspeicher durchsuchen« . Er erhält ein Dateimanager-Fenster, in dem er eine Imagedatei aus dem Gast des Vsphere-Clients in den Datastore hochladen kann (Abbildung 5).

Abbildung 5: Die Linux-Livedistribution Parted Magic dient zum Testen des Setups. Das ISO-Image landet via Vsphere-Client im Datastore.

Mit einem Rechtsklick auf den Cluster »myCluster« lässt sich die neue VM anlegen. Der Admin verwendet eine typische Konfiguration, verpasst der VM den Namen »Live-Linux« und wählt einen beliebigen Host aus. Als Zielspeicher kommt nur der Cluster-Datastore »myCluStore« in Frage. Das Gastbetriebssystem ist ein 32-Bit-Linux, mit Kernel 2.6 und einer virtuellen Festplatte von 1 GByte Größe.

Im Wizard ist dabei nur wichtig, das Optionsfeld zum Bearbeiten der Einstellungen der VM (um das ISO-File für den Bootvorgang auszuwählen) sowie »Beim Einschalten verbinden« zu aktivieren. Damit die Nested VM über den virtualisierten ESX-Host eine Netzwerkverbindung nach außen herstellen kann, muss der ESX-Gast außerdem den Vmnet-Adapter von VMware Player oder VMware Workstation in den Promiscuous Mode setzen können. Wer die weiter oben erwähnte Warnmeldung ignoriert hat, sollte nun den Workaround nachholen [10].

Gastfreundlich

Startet die Linux-Live-VM und ist der Ethernet-Adapter per DHCP konfiguriert, dann bekommt die VM eine Adresse vom DHCP-Dienst des VMware Player, also von außen. Damit lässt sich die Nested VM auch per SSH vom Hostsystem des VMware Player erreichen.

Hat bis hierher alles reibungslos funktioniert, bietet sich gleich der Versuch an, die VM live auf den anderen Gastgeber zu migrieren. Ein Rechtsklick auf die VM im Inventory des Vsphere-Clients zeigt den Eintrag »Migrieren« im Kontextmenü. Den Zielhost für die Migration definiert der nächste Schritt.

Wer beobachten will, ob sich die Migration nach außen bemerkbar macht, pingt die virtuelle Maschine vom Hostssystem aus an. Abgesehen von einzelnen Antwortpaketen sollte keine Verzögerung messbar sein (Abbildung 6).

Abbildung 6: Den Fortschritt der Livemigration des Linux-Gastes verfolgt der Admin im unteren Abschnitt des Vsphere-Clients. Der Linux-Anwender wird dagegen nichts bemerken.

Mobile private Cloud

Dieser Artikel beweist: Ein modernes Notebook mit ausreichend RAM eignet sich durchaus als Plattform für ein umfangreiches, kompliziert verschachteltes virtuelles Demosetup (Abbildung 7). Etwas weniger Ressourcen reichen für den, der sich einen Gast sparen und das I-SCSI-Target statt in einer eigenen VM direkt auf dem Hostsystem von VMware Player aufsetzt. Wer sein Notebook mit Windows betreibt, kann dort direkt den Vsphere-Client installieren und spart sich ebenfalls einen Gast.

Abbildung 7: Das Ergebnis im Betrieb: Der VMware Player virtualisiert auf Fedora 16 zwei ESX-Server, einen Windows-Gast und zwei Linuxe.

Prinzipiell kann solche verschachtelten Setups nicht nur der kommerzielle Platzhirsch [11] aufbauen, auch freie Hypervisoren wie KVM machen’s möglich. Die unter der Regie von Red Hat entwickelten Verwaltungswerkzeuge Libvirt und Virtual Machine Manager (Virt-manager), sind in den gängigen Linux-Distributionen enthalten, mit ihnen lassen sich virtuelle Maschinen ähnlich komfortabel wie bei VMware Player oder Workstation erstellen und verwalten.

Darüber hinaus existieren mit Proxmox-VE [12] auch Lösungen, mit denen sich ähnlich komplexe Demosetups, also Gast in Gast, auf Basis von KVM realisierbar sind. Doch in Sachen Management, High Availability und dynamische Ressourcenverwaltung hat VMware weiterhin die Nase vorn. (mfe)