So möchte man das haben. Jörg Möllenkamp hat in seinem Blog eine einfache Möglichkeit beschrieben um ZFS Snapshots zu erstellen.
Category Archives: Technical
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
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
floek goes OpenSolaris: Updates
Aktuell experimentiere ich mit OpenSolaris herum. Heute: Updates. Updates für z.B. Solaris 10 sind ja ziemlich übel. Man muss sich erst mal ein Programm aus dem Internet ziehen und damit kann man dann Updates machen. Dieses Manko wurde bei OpenSolaris behoben. Es gibt keine Patches, sondern nur neue Paketversionen, wie es z.B. auch Debian macht. Das Tool der Wahl ist pkg
. Allerdings arbeitet OpenSolaris dann ZFS hier ziemlich intelligent. Aktualisiert man sein Betriebssystem mit pkg image-update -v
werden die aktuellen Paketversionen installiert. Nach Abschluss erhält man folgende Meldung:
Ein Klon von opensolaris existiert und ist aktualisiert und aktiviert worden.
Beim nächsten Start wird die Startumgebung opensolaris-1 auf '/' geladen.
Starten Sie neu, wenn Sie zum Wechsel auf diese aktualisierte SU bereit sind.
Möglicherweise funktioniert ein reboot nun erst mal nicht. Hintergrund: OpenSolaris klont die aktuelle Boot Umgebung per Snapshot und installiert die Patches nur in diesem Klon. Dadurch kann man bei Problemen immer wieder in den alten Zustand vor der Aktualisierung zurückkehren. Der Klon verbraucht auch nur Speicherplatz für die Änderungen gegenüber der alten Version. Im Grub gibt es einen neuen Eintrag, welcher standardmäßig ausgewählt wird. Falls sich dieser nicht booten läßt sollte man den Eintrag händisch auswählen, der vor dem patchen gebootet wurde. Dann hilft es sich mit beadm list
alle Boot Umgebungen anzuzeigen und die neu erstelle mit beadm mount /mnt
in das System einzubinden. Anschließend braucht es noch /mnt/boot/solaris/bin/update_grub -R /mnt
um grub auf der neuen Umgebung zu installieren. Funktioniert die neue Boot Umgebung problemlos, kann man die alte(n) mit beadm destroy
wieder löschen.
Migration zu OpenSolaris und ZFS
Ich überlege meine Kiste auf OpenSolaris mit ZFS und xVM zu migrieren. Gründe gibt es:
Für das Klonen von VMs braucht es nur Speicherplatz für die Unterschiede der VMs. Außerdem hat ZFS mit Snapshots, Volume Manager und vor allem RaidZ schon tolle Features:
floek.net goes SSL
Ich habe mir mal bei https://www.startssl.com ein kostenfreies SSL Zertifikat geholt. floek.net läuft somit ab sofort über https.
Blog roundup 2009
So lange nicht mehr geblogt. Da ich aber kürzlich mal wieder auf die Idee gekommen bin mein WordPress zu aktualisieren, habe ich gleich mal etwas aufgeräumt und der Seite ein neues Bild verpasst. Ich bin natürlich letztes Jahr nicht untätig gewesen. Es gab allerdings zu Hause und @work viel zu tun. Leider hat es sich nicht bewährt das Alix Board gleich noch als Fileserver (über USB Platten) mit zu nutzen. Nach längerer erfolgloser Suche nach einem geeigneten NAS (am besten mit Geode Chip und der Möglichkeit openvpn zu nutzen), habe ich mich aus Kostengründen dazu entschieden wieder einen Homeserver aufzubauen. Um den Stromverbrauch in Grenzen zu halten und trotzdem ordentliche Performance bei OpenVPN zu haben, habe ich mit ein Board mit Atom 330 CPU gekauft. Für die Nutzung als Server im Keller hat ein einfaches Intel Board mit 2 GB RAM dicke ausgereicht. Das Ganze dann in ein altes Standard-ATX Gehäuse gepackt, Ubuntu 8.04 LTS Server auf einen 4 GB USB Stick installiert und schon war der Homeserver fertig. Ich habe mich noch entschieden 2x1TB Festplatten in das Gehäuse einzubauen und per Software RAID 1 als Dateiablage zu nutzen. Ohne Festplatten braucht das Setup ca. 30 W, was auch nicht viel mehr ist, als ein NAS + Alix. Mit laufenden Festplatten sinds ca. 45-50 W, aber da ich die selten brauche, lasse ich sie nach 20 Minuten einschlafen. Dann noch Monitoring per Nagios auf den RAID Status, sowie den Stromsparmodus der Festplatten gebaut und fertig. Die Kiste steht jetzt im Keller, ist per Gigabit angebunden und spielt Default Gateway, DHCP Server und DNS Relay. Hintendran hängt dann meine Fritzbox für die Telefonie und den Zugang zum Netz per Kabel. Ich bin mit der Zusammenstellung recht zufrieden. Telefon ist von Basteleien am Server nicht betroffen und der Rechner hat genug Performance für alle Aufgaben. Ich bekomme locker 16-20 MBit über das OpenVPN drüber, was sogar für FullHD ausreichend ist.