xVM finally dead :-(

Leider scheint die Solaris Portierung von Xen nun endg├╝ltig rausgeflogen zu sein. Nach einem Upgrade von Solaris 11 Express auf Solaris 11 gibt es leider weder einen xend noch das Hypervisorfile xen.gz. Um das offizielle Statement hierzu zu finden musste man etwas suchen. Aus http://www.oracle.com/technetwork/systems/end-of-notices/eonsolaris11-392732.html:

xVM Hypervisor
xVM hypervisor, the Oracle Solaris Xen-based hypervisor for x86 systems, has been removed. Oracle offers two x86-based hypervisor solutions for Oracle Solaris users: Oracle VM Server for x86 and Oracle VM VirtualBox. See http://www.oracle.com/virtualization

Schade ­čÖü

Xen + ZFS in a box performance

Leider musste ich immer wieder feststellen, dass ZFS sehr (und ich meine sehr) Performance hungrig ist. Dies f├╝hrt immer wieder dazu, dass die Performance der VMs die im xVM laufen beeintr├Ąchtigt wird. Workaround: PIN der Dom0 CPU auf einen Core und Nutzung der verbleibenden Cores f├╝r die VMs. Dies geht im laufenden Betrieb so:


xm vcpu-set Domain-0 1 # Nur eine vCPU f├╝r die Dom0
xm vcpu-pin Domain-0 0 0 # Diese eine vCPU soll nur auf Core 0 laufen
xm vcpu-pin VM all 1-3 # Die vCPU(s) der VM sollen nur Cords 1-3 nutzen

Erfreulicherweise bekommt die libvirt dies auch gleich mit und fügt ein <vcpu cpuset='1-3'>1</vcpu> in die XML Config mit ein.

Damit die Dom0 nach einem Reboot mit einer vCPU und nur auf Core 0 l├Ąuft m├╝ssen dem Hypervisor die Optionen dom0_vcpus_pin=true dom0_max_vcpus=1 mitgegeben werden.

ZFS root Dateisystem

Leider musste ich diese Tage ein paar Einschr├Ąnkungen des ZFS Pools mit dem root Dateisystem meines Servers feststellen. Aktuell verwende ich zwei gespiegelte Platten f├╝r diesen Pool. Erster Punkt: Schreiben ist aus unerfindlichen Gr├╝nden langsam. Mehr wie 2-3 MB/s gehen nicht. Daher war der Plan den Spiegel um zwei weitere Platten zu erweitern (Stripped Mirror). Anscheinend geht das aber nicht. Man kann den Root Pool nur zu einem dreifach Spiegel erweitern. Das Anh├Ąngen eines weiteren Mirrors aus zwei Platten wird nicht erlaubt und schl├Ągt mit der Meldung
„cannot add to ‚rpool‘: root pool can not have multiple vdevs or separate logs“
fehl. Somit macht es f├╝r mich keinen Sinn den Root Pool intensiver zu Nutzen. Man braucht immer einen zweiten Pool.

OpenSolaris is dead! (Aber noch nicht ganz)

Aufgrund eines Hardwareproblems bin ich unverhofft dazu gekommen meine OpenSolaris Virtualisierungsumgebung noch einmal zu aktualisieren. Somit l├Ąuft das ganze nun auf snv_134 mit Xen/xVM 3.4. Bisher l├Ąuft alles stabil wie auch zuvor, aber mit einigen neueren Features. Zuvor (2009.06) gab es nur Xen/xVM 3.0, was dazu f├╝hrte, dass man nur eine Linux Distribution mit xen Kernel paravirtualisiert laufen lassen konnte. Leider sind diese Kernel bei den Distributionen zwischenzeitlich eine Seltenheit. Bei Ubuntu war 8.10 das letzte Release, was einen passenden Kernel mitgebracht hat. Seither gibt es nur noch Kernel mit Support f├╝r pvops. Dank der neuen Xen Version kann ich diese nun auch nutzen und bekomme Support f├╝r z.B. Ubuntu 10.04 LTS. Hurray! Weiterhin gibt es einige neue ZFS Features, unter anderen Deduplication. Eigentlich schon schade, dass diese Distribution nun sterben muss. Man kann nur hoffen, dass die Jungs von Illumos Gas geben und daraus eine freie Alternative zu Solaris 11 entsteht. Ich hoffe auch das der xVM Support erhalten bleibt, da die einzige Alternative in Sachen Virtualisierung mit ZFS Support eigentlich nur in FreeBSD mit ZFS und VirtualBox besteht. Diese L├Âsung muss allerdings erst zeigen ob sie genau so schnell und stabil ist wie Xen.

Wer ├╝brigens sein OpenSolaris auf eines der letzten Releases von Oracle aktualisieren m├Âchte, kann hierzu ein Repository von Illumos nutzen und somit nochmal auf svn_145 aktualisieren. Leider ist hier aber der xVM Support kaputt. Der xend st├╝rzt beim Starten mit einer python Fehlermeldung ab. Wer es dennoch probieren m├Âchte, hier der Link:
http://www.illumos.org/projects/illumos-gate/wiki/How_To_Build_Illumos

Fazit: OpenSolaris ist tot! Aber noch nicht ganz und hoffentlich gibt es eine Wiedergeburt mit Illumos

floek goes OpenSolaris: xVM tuning

Hier noch einige Tuning-Tips f├╝r xVM und ZFS:
Damit ZFS nicht zu viel RAM frisst sollte man in /etc/system die Zeile

set zfs:zfs_arc_max = 0x10000000

hinzuf├╝gen.

Wenn eine VM abst├╝rzt wird ein Dump unter /var/xen/dump geschrieben. Da hierdurch ggf. das root Filesystem vollgeschrieben werden kann, sollte man dieses Verzeichnis in ein eigenes Dateisystem legen:

zfs create -o mountpoint=/var/xen/dump,quota=2G rpool/xendumps

Die CPU und RAM Ressourcen der Dom0 m├Âchte man ggf. ebenfalls beschr├Ąnken. Hierzu ├╝bergibt man geeignete Parameter an den Hypervisor, indem man in /rpool/boot/grub/menu.lst den Aufruf des Xen Hypervisors z.B. wie folgt anpasst:

kernel$ /boot/$ISADIR/xen.gz console=com1 com1=auto dom0_mem=1024M dom0_max_vcpus=1

Weiterhin sollte man noch folgende Option setzen und den xend neu starten:

svccfg -s svc:/system/xvm/xend setprop config/dom0-min-mem = 2334
svcadm refresh svc:/system/xvm/xend:default
svcadm restart svc:/system/xvm/xend:default

Schlussendlich sollte man noch den gdm deaktivieren:

svcadm disable gdm

Quelle: http://hub.opensolaris.org/bin/view/Community+Group+xen/configuring-dom0

floek goes OpenSolaris: xVM

Die Xen Implementierung in OpenSolaris nennt sich aus markenrechtlichen Gr├╝nden xVM und wird standardm├Ą├čig mitgeliefert. Die Installation erfolgt ├╝ber das Paketmanagement:

pkg install SUNWxvm SUNWxvmdom SUNWxvmhvm SUNWxvmipa SUNWxvmpv xvm xvm-gui SUNWlibvirt SUNWvirt-manager SUNWvirtinst


Nach Abschluss der Installation sollte man folgende Dienste aktivieren (svcadm enable dienst):

online 11:10:27 svc:/system/xvm/vnc-config:default
online 11:39:10 svc:/system/xvm/store:default
online 11:39:11 svc:/system/xvm/xend:default
online 11:39:12 svc:/system/xvm/console:default
online 11:39:12 svc:/system/xvm/domains:default
online 11:55:04 svc:/system/xvm/virtd:default


Jetzt noch einen zus├Ątzlichen Eintrag im grub Men├╝ erstellen, damit der Hypevisor auch vor dem OpenSolaris Kernel geladen wird. Hier zu sollte folgender Eintrag zu /rpool/boot/grub/menu.lst hinzugef├╝gt werden (In meinem Beispiel liegt das System auf dem zpool rpool):

title OpenSolaris 2009.06 xVM
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/opensolaris
splashimage /boot/solaris.xpm
foreground d25f00
background 115d93
kernel$ /boot/$ISADIR/xen.gz
module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=graphics
module$ /platform/i86pc/$ISADIR/boot_archive


Nach einem Reboot in OpenSolaris 2009.06 xVM sollte nun die Virtualisierungsumgebung bereit sein. Dies sieht man am schnellsten ├╝ber virsh list. Hier sollte zumindestens so etwas zur├╝ckgegeben werden:

Id Name State
----------------------------------
0 Domain-0 running

Andernfalls ist wahrscheinlich etwas schief gelaufen. Debugging Informationen gibt es in

  • /var/svc/log/*xvm*
  • /var/log/xen/
  • Jetzt kann man sich einen ZFS Poo erstellen, wenn gew├╝nscht, (zpool create xvmpool raidz2 c7t0d0 c7t1d0 c7t2d0 c7t3d0 c7t4d0) und darin Volumes f├╝r die VMs einrichten (zfs create -V 10G xvmpool/domain). Diese stehen dann unter /dev/zvol/dsk/xvmpool/domain zur Verf├╝gung. VMs lassen sich jetzt z.B. per virt-manager oder virt-install installieren. Hierbei ist das jeweilige zvol als file anzugeben. Falls man bereits vorhandene (Xen) VMs hat, kann man diese z.B. per cat domainimage > /dev/zvol/rdsk/xvmpool/domain importieren. Auch das ggf. vorhandene Xen Configfile l├Ąsst sich per xm create domainconfig importieren. Da allerdings einige Anpassungen notwendig sind und man xVM lieber ├╝ber virsh steuern m├Âchte, empfiehlt es sich gleich das XML Format von virsh zu nutzen. Ich poste hier mal eine Config f├╝r ein paravirtualisiertes Ubuntu, welches als Vorlage genutzt werden kann:

    <domain type='xen'>
    <name>ubuntu</name>
    <bootloader>/usr/lib/xen/bin/pygrub</bootloader>
    <os>
    <type>linux</type>
    </os>
    <memory>262144</memory>
    <vcpu>1</vcpu>
    <on_poweroff>destroy</on_poweroff>
    <on_reboot>restart</on_reboot>
    <on_crash>restart</on_crash>
    <clock offset='utc'/>
    <devices>
    <interface type='bridge'>
    <source bridge='rge0'/>
    <script path='vif-vnic'/>
    </interface>
    <disk type='block' device='disk'>
    <driver name='phy'/>
    <source dev='/dev/zvol/dsk/xvmpool/ubuntu'/>
    <target dev='hda'/>
    </disk>
    <console tty='/dev/pts/7'/>
    </devices>
    </domain>

    Das ganze als z.B. ubuntu.xml speichern, via virsh define ubuntu.xml importieren, mit virsh start ubuntu starten und ├╝ber virt-console ubuntu beim booten zuschauen.
    Neue VMs habe ich einfach voll virtualisiert installiert und dann innerhalb der VM einen Xen Kernel installiert. Bei ubuntu muss man aufpassen, dass ein update-grub in der Vollvirtualisierung keinen Grub Eintrag f├╝r den Xen Kernel erzeugt. Diesen muss man h├Ąndisch zur /boot/grub/menu.lst hinzuf├╝gen und als default Kernel einrichten. Anschlie├čend kann man die Config per virsh dumpxml domain > domain.xml exportieren, anhand obiger Beispielconfig anpassen und per virsh define domain.xml wieder importieren.

    floek goes OpenSolaris: nrpe

    Gl├╝cklicherweise gibt es Nagios Plugins und den nrpe Daemon f├╝r das Monitoring im contrib Repository. Hier gibt es Pakete die von der Community bereitgestellt werden und einen Pr├╝fprozess durchlaufen haben. Das contrib Repository l├Ąsst sich wie folgt zus├Ątzlich zum normalen Repository nutzen:
    pkg set-authority -O http://pkg.opensolaris.org/contrib/ contrib
    Nun installiert pkg install nrpe nagios-plugins die binaries des nrpe daemon und der Nagios Plugins. Die Files liegen unter /usr/nagios/. Jetzt noch /usr/nagios/etc/nrpe.cfg anpassen und ggf. noch einen User und eine Gruppe f├╝r den nrpe daemon anlegen und wir sind fasst fertig. Ich habe einen Blog Eintrag gefunden, der beschreibt, wie man den nrpe daemon unter SMF zum laufen bekommt. Hierzu http://blogs.digitar.com/media/2/nrpe_smf.zip runterladen, entpacken, in das neue Verzeichniss wechseln und noch etwas die Pfade in ./manifest/nagios-nrpe.xml und ./method/nagios-nrpe anpassen. Jetzt kann man via

    # cp ./manifest/nagios-nrpe.xml /var/svc/manifest/network/
    # cp ./method/nagios-nrpe /lib/svc/method/
    # svccfg import /var/svc/manifest/network/nagios-nrpe.xml
    # chmod +x /lib/svc/method/nagios-nrpe

    den SMF Dienst installieren. Ist alles gut gegangen startet ein svcadm enable nrpe den nrpe Dienst. Falls was schief gegangen ist kann man in /var/svc/log/network-nagios-nrpe:default.log nachschauen welche Fehlermeldung ausgegeben wird.

    floek goes OpenSolaris: OpenSolaris Minimalinstallation auf USB Stick

    Die Standardinstallation von OpenSolaris ben├Âtigt ca. 3 GB Platz und bringt viel Zeug mit was kein Mensch auf einem Server braucht. Unter anderem Gnome, Firefox, Evolution uvm. Leider kann man mit dem GUI Installer auf der Live CD nicht ausw├Ąhlen was man denn installieren m├Âchte. Allerdings gibt es ein Script von Mark Johnson, welches hier hilft. Man bootet den Rechner von der Live CD. Hier reicht es in die Text Konsole zu booten (Login: jack/jack, root/opensolaris) und das Script per wget http://blogs.sun.com/mrj/resource/slim-guest-installer;chmod +x slim-guest-installer runterzuladen. Falls man auf USB Sticks installieren m├Âchte muss man das Script noch etwas anpassen, damit diese auch f├╝r die Installation zur Verf├╝gung stehen: vi slim-guest-installer +74. Ersetze ['/usr/sbin/format'] durch ['/usr/sbin/format', '-e'], nun werden vom Script auch USB Sticks gefunden. Jetzt kann man per ./slim-guest-installer die Installation starten. Festplatte oder USB Stick ausw├Ąhlen und los gehts. Allerdings wird OpenSolaris tats├Ąchlich sehr sliminstalliert. So fehlen in der Installation ggf. Treiber f├╝r Netzwerk und SATA Platten. SSH oder nen vi gibt es auch erst mal nicht. Daher sollte man Nach Abschluss des Scripts gleich die notwendigen Pakete nachinstallieren. Zuerst muss man das Verzeichnis herausfinden, wo die neue Installation gemountet wurde. Hier hilft ein einfaches mount. Anschlie├čend kann man die Pakete per

    /bin/pkg -R install
    SUNWrge
    SUNWsshd
    SUNWssh
    SUNWsshcu
    SUNWvim
    SUNWahc

    nach installieren. Nun noch ein reboot und schon kann man sich in seinem Minimal-OpenSolaris einloggen. Die Netzwerkkonfiguration muss nun noch manuell erledigt werden. Ich empfehle erst mal SSH an den Start zu bekommen und dann den Rest remote zu machen. Erst mal braucht es eine IP: ifconfig rge0 plumb 192.168.1.2/24 up. In meinem Fall fehlten noch die SSH-Keys f├╝r den Host. Diese habe ich per

    ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N "" -C ""
    ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N "" -C ""

    nachinstalliert. Danach svcadm enable ssh und einloggen per ssh sollte m├Âglich sein. Jetzt muss man noch die Netzwerkkonfiguration nach der alten Methode gemacht werden. Ich gehe hier nicht weiter darauf ein. Nur ein paar Files die angepasst werden m├╝ssen gebe ich hier an:

  • /etc/hostname.rge0
  • /etc/netmasks
  • /etc/hosts
  • /etc/nsswitch.conf
  • /etc/resolv.conf
  • /etc/defaultrouter
  • floek goes OpenSolaris: Boot from USB mirror

    Booten von Festplatten? Warum eigentlich? Wenn ich meine 5x 500GB Platten zu einem gro├čen Array zusammenbauen m├Âchte, kann ich nicht davon booten. Au├čerdem braucht es f├╝r ein Betriebssystem ja nicht so viel Platz. Also: Zwei 8 GB USB Sticks gekauft, einen Mirror (RAID-1) dr├╝ber gemacht und davon gebootet. Los gehts:
    Continue reading