Die CeBIT naht mit großen Schritten und ich hatte mich darum gerissen, unsere Ultra 40 M2 für den Arbeitsplatz  "Solaris und Sun xVM-Server" vorzubereiten. Solaris 10 und Solaris Express (selbst im Dual Boot) auf eine Workstation zu bringen, ist keine großartige Sache. Weitaus spannender ist es, Sun xVM-Server mit einzurichten und einige verschiedene OS-Varianten in den DomU zu installieren. Immerhin ist der Sun xVM-Server (basiert auf der Arbeit der XEN Community) in OpenSolaris noch nicht fertig, befindet sich also noch in der Entwicklung. Das Interesse ist trotzdem beträchtlich und so entschieden wir, den aktuellen Stand der Arbeiten auf der CeBIT zu zeigen. Nachdem die Maschine nun heute auf der CeBIT aufgestellt wird, wollte ich einmal ein paar Erfahrungen niederschreiben, die ich während der Installation gesammelt habe.

• Auf dem System sollte in der dom0 ein aktuelles Solaris Express mit allen Developer Tools laufen.
• Zusätzlich sollten eine Solaris Zone und eine branded Zone (BrandZ) mit Linux laufen.
• In verschiedenen domU sollten Linux, Solaris und Windows laufen.
• Schön wäre noch eine domU mit dem Preview 2 von Project Indiana.
• Zum vereinfachten Management der Domains sollte eine Version des Virtual Machine Manager installiert sein.

Also ans Werk:

Ich installiere hier Windows XP, Solaris 10 8/07, Nevada Build 82 und den Preview 2 vom Projekt Indiana. Fedora selbst habe ich nicht installiert, sondern ein fertiges xVM-Image von einem Kollegen bekommen und es benutzt. Das Aufsetzen der Zonen ist relativ einfach und z.B. im Solaris Container Leitfaden 2.0 beschrieben.
 
Da ich eine U40M2 habe, stehen mir mit dem Sun xVM-Server alle Möglichkeiten offen.

• pvm-DomU's sind paravirtualisierte Domains, die keine besondere Unterstützung durch die benutzte CPU/Hardware benötigen. Allerdings muss hier das in die DomU zu installierende OS modifiziert sein und paravirtualisierte Treiber für I/O (Netzwerk und Disk) enthalten. Eine pvm-DomU kann mit 32- und 64-bit benutzt werden.
  
• hvm-DomU's sind Domains mit Hardware-Unterstützung. Die CPU's müssen entsprechende Erweiterungen enthalten, damit an dem benutzen OS keine Modifikationen vorgenommen werden müssen. Manchmal ist es ja auch nicht möglich, das OS zu modifizieren. Claudia hat in ihrem Blog eine Liste der CPU's mit aufgenommen, die diese Erweiterungen enthalten. Der Sun xVM-Server basiert zur Zeit noch auf XEN 3.0.4 und unterstützt wegen einem Bug nur 32bit-OS. Mit einem zukünftigen Solaris Express Build sollen auch 64bit OS funktionieren.
  

Nach der Liste von oben ergeben sich folgende DomU's:

• hvm-s10807: Dieses Solaris 10 enthält noch keine paravirtualisierten Treiber.
• pvm-nvx82: Solaris Express Community Edition Build82 enthält bereits paravirtualisierte Treiber.
• hvm-Indiana2: Den Preview 2 von Projekt Indiana wollte ich auch in einer hvm-DomU haben.
  
• hvm-winxp32: Windows XP sollte nicht modifiziert werden.
• pvm-fedora8: Fedora 8 enthält auch bereits paravirtualisierte Treiber.
  

Nachdem Claudia Hildebrandt auf der Maschine bereits für einen anderen Event die Solaris Express Community Edition - Build 82 und den Virtual Machine Manager installiert hatte, mußte ich das wenigstens nicht mehr machen. Danke Claudia !

Bleiben also noch die domU: Bei einer frühere Testinstallation hatte sich gezeigt, das eine domU schneller ist, wenn ihr als virtuelle Platte ein zvol aus ZFS zugeordnet wird. Dazu wird ein zpool erzeugt und ein zfs angelegt. Dort werden die entsprechenden zvols erzeugt. Da nur eine Platte in der U40 drin ist, wird ein großes Slice dafür vorgesehen.

    zpool create cebit c1t0d0s5
    zfs create cebit/xvm

    zfs create -V 10g cebit/xvm/hvm-s10807
    zfs create -V 10g cebit/xvm/hvm-indiana2
    zfs create -V 10g cebit/xvm/pvm-nvx82

    Für Windows XP und Fedora werden Disk-Images benutzt, die in /cebit/xvm abgelegt werden.


Die iso-Images und noch ein paar andere Packages für die Installation werden auf einem separaten zpool abgelegt, auf den später aus den DomU z.B. per sftp zugegriffen werden kann.

    zpool create archive c0t0d0s6
    zfs create archive/img

Zum Erzeugen und Installieren der DomU wird virt-install(1M) benutzt. Das erscheint aufwändiger als durch das einfache Einspielen einer Konfigurationsdatei, allerdings sieht man so durch das Setzen diverser Optionen am Anfang noch was man hier tut. Der Lerneffekt ist also höher.

Virt-install erzeugt ein vnic (virtuelles physikalisches Netzwerkinterface), bindet das an die DomU, öffnet eine Konsole und beginnt mit der Installation. Das vnic wird auf dem ersten physikalischen Interface erzeugt, das ein dladm show-link ausgibt. Wie man einstellen kann, das ein anderes Interface genommen wird, ist in xend(1M) beschrieben. Die geöffnete Konsole ist bei hvm-Domains grafisch (Emulation einer Cirrus vga-Karte) und bei pvm-Domains eine Text-Konsole.

hvm-s10807:

virt-install --hvm --name=hvm-s10807 --ram=1024 --file=/dev/zvol/dsk/cebit/xvm/hvm-s10807 --vnc \ --cdrom=/archive/img/s10x807-dvd.iso

Die Installation läuft wie gewohnt durch. Das vnic wird vom Solaris als rtls0 erkannt. Nach der fertigen Installation und dem Reboot (32bit) erscheint in der DomU-Konsole der dtlogin-Screen.

pvm-nx82:

virt-install --paravirt --name=pvm-nvx82 --ram=1024 --file=/dev/zvol/dsk/cebit/xvm/pvm-nvx82 \ --nographics --cdrom=/archive/img/nvx82-dvd.iso

Da es sich hier um eine pvm-Domain handelt, bootet das System nach der Installation den 64bit-Kernel. In der DomU-Konsole ist aber keine Grafik möglich. Deshalb erscheint der ascii-Konsole Login. Wer hier ein grafisches Login möchte, sollte den dtlogin gegen den Xvnc-Server starten.

 hvm-Indiana2:

virt-install --hvm --name=hvm-indiana2 --ram=1024 --file=/dev/zvol/dsk/cebit/xvm/hvm-indiana2 --vnc \ --cdrom=/archive/img/in-preview2.iso

Die Installation von Indiana2 in einer hvm-DomU ist etwas trickreich und wird noch von einigen "workarounds" begleitet.

Indiana2 bootet zwar, startet aber nicht den grafischen login-Screen. Xorg kann nicht starten, da in dem Indiana2-Preview das cirrus(7) Video Modul fehlt, das für die DomU-Konsole benötigt wird. Hier hilft ein Trick, den Stephen Hahn in seinem Blog beschrieben hat. Man benutzt einfach den vesa-Treiber. Dazu muss eine entsprechend modifizierte xorg.conf in /etc/X11 abgelegt werden. (Das root-Passwort des iso-Images ist opensolaris). Anders als bei Stephen Hahn beschrieben kann man das xorg.conf-File schon vorbereitet irgendwo im Netz liegen haben und kopiert sich das mit sftp in das laufende Indiana2 hinein. Danach mit einem svcadm restart gdm den login-Screen neu starten, einloggen und die Indiana2 Installation starten.

Irgendwie hat bootadm update-archive noch ein Problem, wenn Indiana2 in einer domU installiert ist. Es hat sich gezeigt, das der find ... (siehe ptree von bootadm) nicht fertig wird. Als workaround wird das find "gekillt", damit die Installation weiterläuft. Als Sicherheit (falls doch mal ein defektes oder inkonsistentes /platform/i86pc/boot_archive entsteht, kann man davon noch einmal eine Kopie nach /platform/i86pc/boot_archive.old spielen, die man alternativ beim grub angibt. Wenn dann das boot_archive.old benutzt wurde, muß nach dem erfolgten Boot noch ein bootadm update-archive aufgerufen werden. Nach einem erneuten reboot ist das Archive konsistent und benutzbar. ... Hier ist also noch etwas "Feintuning" notwendig.

 hvm-winxp32:

 Vor der Installation muß für Windows eine virtuelle Platte erzeugt werden. Dazu kann das Programm qemu-img benutzt werden.

qemu-img create /cebit/xvm/winxp32.raw 10g
virt-install --hvm --name=hvm-winxp32 --ram=1024 --file=/cebit/xvm/winxp32.raw --filesize=10 --vnc \ --os-type=windows --cdrom=/archive/img/winxp32-sp2.iso

Die Installation läuft wie gewohnt durch. Irgendwann wird aber Windows neu gestartet und möchte Software nachladen. Bei dem Reboot stellt sich heraus, das virt-install sein virtuelles DVD-ROM "verloren" hat. Ein Workaround ist hier einfach die DomU zu stoppen und die Domain mit xm delete hvm-winxp32 zu löschen. Ein erneuter Aufruf von virt-install mit den obigen Paramtern stellt fest, das die Installation schon da ist und setzt an der richtigen Stelle fort (hmm darauf muss man erst mal kommen ...aber google findet soetwas heraus).

Falls beim späteren Start der hvm-winxp32-Domain die Meldung kommt, es sei nicht genug Speicher vorhanden, hilft es, die Dom0 im Speicherverbrauch zu begrenzen. Das kann man mit xm(1M) oder noch einfacher mit dem virt-manager erledigen.

 So, die meiste Arbeit ist nun getan. Es schließen sich noch ein paar Kleinigkeiten in der Installation der einzelnen DomU an, die OS-spezifisch sind. So wurden z.B. noch in hvm-s10807 alle aktuellen Patches installiert.

Wer eine nicht-US-Tastatur benutzt - davon soll es ja in Deutschland einige geben - wird nach dem Neustart seiner DomU's ein "eigenartiges" Keymapping feststellen. Das kann behoben werden, wenn beim Aufruf von virt-install zusätzlich noch der Parameter --keymap=de übergeben wird. Das hat bei mir allerdings nicht richtig funktioniert. Deshalb habe ich mir hier für die betroffenen Domains mit einem "hack" geholfen:

xm list -l <domain> >/tmp/dom.xm      - zum Ausgeben der DomU Konfiguration
xm delete <domain>                            - Domain löschen
vi /tmp/dom.xm                                    - Eintragen von (keymap de) in der Abteilung (hvm
xm new -F /tmp/dom.xm                      - Anlegen der DomU ohne Installation

Nach dem nächsten Start der Domain stimmt das Keymapping.

Weiterhin hat sich gezeigt, das es besser ist, das USB Pointing Device von der Arbeit mit relativen Koordinaten (Maus) auf absolute Koordinaten (Tablet) umzustellen. Das führt zu einer besseren Arbeit mit dem Maus-Zeiger in den vnc-Fenstern. Dazu sind in die obere dom.xm-Datei noch die folgenden Zeilen in der (hvm-Abteilung einzufügen.

(usb 1)
(usbdevice tablet)

Für die Windows-DomU führt diese Modifikation nach dem nächsten Reboot zur Neuinstallation von Treibern. Dieser Vorgang dauert in der DomU sehr lange. Man hat schon fast den Eindruck, das Windows XP abgestürzt ist und dann wird es doch fertig... also ... nur Geduld.

Endlich fertig !

Insgesamt geht mit dem Sun xVM-Server schon eine ganze Menge, obwohl dieses Feature ja noch in der Entwicklung ist. Aber gerade zusammen mit der Nutzung von zvols in ZFS macht der xVM-Server dann richtig Spass. Man kann z.B. einfach zfs snapshot benutzen, um Domains zu clonen...oder wie ich Sicherrungskopien machen, damit nach einer "Fehlinstallation" nicht alles noch einmal von vorne installiert werden muß. Dann reicht ein einfaches zfs rollback.

So, das war mal ein sehr länglicher Eintrag. Ich hoffe es ist nützlich für den Einen oder Anderen, der sich hier versucht (Ich hoffe, das noch einige Leser bis hier unten durchgehalten haben.)

Einige der Erfahrungen kann man natürlich auch persönlich diskutieren. Vom 6. - 9.3.2008 werde ich auf der CeBIT an der U40 stehen und sicherlich eine Menge interessanter Diskussionen nicht nur um den xVM-Server haben.