Mittwoch, 18. September 2013

ISO Image zu libvirt Storage Pool hinzufügen

Ich verwende momentan einen libvirt Storage Pool (Verzeichnis im Host Dateisystem, z.B. /home/libvirt/disk-images) um meine ISO Installer Images zu verwalten.
Wenn man nun im laufenden Betrieb neue Images hinzufügen möchte, so stellt sich die Frage wie man dies ohne Neustart von libvirt realisieren kann. Mit
virsh pool-list
Name                 State      Autostart
-----------------------------------------
virtual-machine-images active     yes      
virtual-machine-install-images active     yes      
können wir uns die genaue Storage Pool Bezeichnung anzeigen lassen. Mein Storage Pool für die Installer Images heisst also virtual-machine-install-images. Wir verwenden diesen später um den Pool zu aktualisieren.

Man geht hierfür also wie folgt vor:
  1. cp <image> /home/libvirt/disk-images
  2. virsh pool-refresh virtual-machine-install-images
Nun können wir die neu hinzugefügten Images verwenden.

Dienstag, 17. September 2013

Increase Attachment Size, Anhanggrösse erweitern mit Squirrelmail, lighttpd, nginx (Debian Wheezy)

Ich verwende momentan Squirrelmail als Mail Frontend welches durch lighttpd bereitgestellt wird. nginx dient als http Reverse Proxy um auf die entsprechende Maschine zugreifen zu können.
Um Anhänge grösser als 2MB (Defaultwert aus php.ini) über Squirrelmail versenden zu können müssen wir folgende Anpassungen durchführen:
  1. Änderung des Wertes upload_max_filesize auf z.B. 10MB
  2. Änderung des Wertes post_max_size auf einen Wert > upload_max_filesize
  3. Änderung des Wertes memory_limit auf einen Wert > post_max_size
  4. Restart lighttpd
    service lighttpd restart
  5. Lokalisieren der nginx.conf (/etc/nginx/conf.d/default) und einfügen des folgenden Wertes in die "server" Sektion
    client_max_body_size 12M;
Die Änderung unter Punkt 5 ist nur notwendig wenn nginx als Proxy vor lighttpd/apache geschalten wurde. Man erhält in diesem Falle nämlich folgende Fehlermeldung:
Nginx: 413 Request Entity Too Large Error

Montag, 16. September 2013

Continuous Integration für CMake basierte Projekte mit Jenkins und CMakeBuilder Plugin

Wer bereits jenkins/hudson als Continuous Integration System für seine Java? Projekte verwendet, der fragt sich sicherlich früher oder später ob man dieses System nicht auch zum Bauen von C/C++ Projekten einsetzen kann. Dies ist im Prinzip schon out-of-the-box möglich, noch einfacher und wesentlich besser zu integrieren ist dies allerdings bei CMake basierten Projekten mit Hilfe des cmakebuilder Plugins möglich.

Hierzu installiert man im jenkins des cmakebuilder Plugin und erhält dann einen neuen Build-Step (CMake Build). Hier konfiguriert man das Plugin entsprechend der Anleitung/Beschreibung des Autors.
Bei mir habe ich als Source Directory ".", als Build Directory "./build" und als Install Directory "./install" angegeben. Somit erfolgt das komplette bauen und installieren in den Workspace Verzeichnis des Builds.
Selbstverständlich muss man noch sicherstellen das die entsprechenden Build Tools (cmake, make, gcc, ...) auf den Build Node zur Verfügung stehen. Unter Debian kann man diese ggf. so nachinstallieren.
apt-get install cmake build-essential

Referenzen:

  • https://wiki.jenkins-ci.org/display/JENKINS/cmakebuilder+Plugin
  • http://schneide.wordpress.com/2009/11/09/cmake-builder-plugin-reloaded/

Sonntag, 15. September 2013

Hyrbid LVM (Logical Volume Manager) Partitionierung für KVM Gäste (Debian Wheezy)

Dieser Blogpost beschreibt die Verwendung von einer sogenannten "Hybrid LVM Partitionierung" wie zuerst in diesem Blogpost gefunden. Bei dieser Art von Partitionierung ist jedes logische LVM Volume auf dem Host ein vollständiges Dateisystem im Gast. Einzige Ausnahme ist ein kleines logisches Volume welches als Boot Festplatte (mit kleiner Boot Partition) im Gast erscheint.
Diese Art der Partitionierung hat ein paar Vorteile:
  • einfaches Online Backup über LVM Snapshot auf den Host
  • Partitionen können ohne Probleme (zusätzliches Mapping durch kpartx, usw.) am Host gelesen werden
  • sehr einfaches Online Resizing (vergrössern) der Partitionen durch ändern der Grösse des logischen Volumes und vergrössern des Dateisystems im Gast.
  • sehr effizient, z.B. im Vergleich zu reinen Dateisystem Image Dateien


In unserem Beispiel möchte ich eine 32bit virtuelle Maschine erstellen, welche als Jenkins Slave mein Build Cluster um ein 32bit Debian System ergänzen soll. Die Maschine soll ein logisches Volume für root, swap und boot erhalten.

#Mapping: Host -> Gast
/dev/vg0/vmi-jenkins-slave-debian32-boot -> /dev/vda
/dev/vg0/vmi-jenkins-slave-debian32-root -> /dev/vdb
/dev/vg0/vmi-jenkins-slave-debian32-swap -> /dev/vdc
Im Gast werden die virtuellen Disks wie folgt verwendet.
/dev/vda -> Partitionstabelle
         -> + Boot Partition (/dev/vda1)
/dev/vdb -> Mount als ext4 Dateisystem
/dev/vdc -> Mount als Swap Partition
Im folgenden werden wir nun die benötigten logischen Volumes erzeugen. Mein Host System sieht wie folgt aus.
root@xx:~# vgs
  VG   #PV #LV #SN Attr   VSize VFree
  vg0    1  11   0 wz--n- 1,73t 1,56t
Wir haben also eine Volume Gruppe (vg0) welche wir als Storage für unsere virtuellen Maschinen verwenden können. Es empfiehlt sich jedoch eine eigene exklusive Volume Gruppe nur für virtuelle Maschinen zu haben.
Als erstes erzeugen wir  uns nun das Volume (vmi-jenkins-slave-debian32-boot)für die Boot Festplatte (/dev/vda) mit einer Grösse von 256MB.
lvcreate -n vmi-jenkins-slave-debian32-boot -L 256M /dev/vg0
Nun partitionieren wir das Volume mit fdisk mit folgenden Script wie folgt.
fdisk /dev/vg0/vmi-jenkins-slave-debian32-boot << __END__
n
p
1


a
1
w
__END__
Zuerst wird also eine neue (n) primäre (p) 1.Partition (1) erzeugt. Anschliessend bestätigen wir die beiden default Werte (Startsektor und Grösse). Die so erzeugte Partition wird dann noch aktiv geschalten (a 1) und die Partitionsdaten geschrieben (w).
Nun Mappen wir die erste Partition über kpartx und erzeugen ein ext2 Dateisystem für die Bootpartition.
#map/reload partitions
kpartx -a /dev/vg0/vmi-jenkins-slave-debian32-boot
#erzeugt Dateisystem auf erster Partition
mkfs.ext2
/dev/vg0/vmi-jenkins-slave-debian32--boot1
#unmap partitions
kpartx -d
/dev/vg0/vmi-jenkins-slave-debian32-boot
Jetzt müssen wir nur noch die logischen Volumes für die root und swap Partition erzeugen und formatieren.
lvcreate -n vmi-jenkins-slave-debian32-root -L 8G /dev/vg0
mkfs.ext4 /dev/vg0/vmi-jenkins-slave-debian32-root
lvcreate -n vmi-jenkins-slave-debian32-swap -L 2G /dev/vg0
mkswap /dev/vg0/vmi-jenkins-slave-debian32-swap
Wir haben nun 3 logische Volumes in der Volume Gruppe vg0. Das root und das swap Volume beinhalten komplette "Dateisysteme" ohne Partitionstabellen. Das boot Volume ist das einzige Volume welches selbst partitioniert ist und eine ext2 boot Partition beinhaltet. Um die Volumes verwenden zu können müssen wir diese noch in der entsprechenden libvirt Gast Beschreibung bekannt machen. Dies geht in der device Sektion wie folgt...
<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none'/>
  <source dev='/dev/vg0/vmi-jenkins-slave-debian32-boot'/>
  <target dev='vda' bus='virtio'/>
</disk>
<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none'/>
  <source dev='/dev/vg0/vmi-jenkins-slave-debian32-root'/>
  <target dev='vdb' bus='virtio'/>
</disk>
<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none'/>
  <source dev='/dev/vg0/vmi-jenkins-slave-debian32-swap'/>
  <target dev='vdc' bus='virtio'/>
</disk>
Im folgenden Abschnitt werden wir nun den 32bit Gast erzeugen. Hierzu definieren wir zuerst den Gast über ein libvirt xml Template und verbinden uns anschliessend über virt-manager mit dem qemu Hypervisor um den Gast zu installieren. Als erstes erzeugen wir uns ein Template von einen bereits bestehenden Gast.
virsh dumpxml <gast> > vm-templ.xml
In diesem Template machen wir dann folgende Anpassungen.
  • Änderung des Namens unter /domain/name auf den neuen Gast jenkins-slave-debian32
  • Entfernen der UUID unter /domain/uuid da diese bereits vorhanden ist und bei fehlen automatisch neu generiert wird
  • Anpassung/Ergänzen der disk Sektionen unter domain/devices/disk entsprechend obiger Beschreibung
  • Entfernen/Anpassung der MAC Adresse unter /domain/interface/mac
Jetzt können wir mittels des so erstellten Templates die neue virtuelle Maschine erzeugen. Wir verwenden hierzu define damit die virtuelle Maschine noch nicht automatisch startet.
virsh define vm-templ.xml
Nun verwenden wir den virt-manager um mit diesem schnell und komfortabel die Maschine für den initialen Boot vorzubereiten.
virt-manager -c qemu+ssh://root@vm-host/system
Nun nutzen wir den virt-manager um die Bootreihenfolge auf CD-ROM zu ändern, sowie um die Installations-CD zu mounten. Hierzu gehen wir auf Virtual Machine Details und dann auf Anzeige -> Details und ändern die Bootreihenfolge auf CD-ROM, ausserdem verbinden wir ein ISO-Image mit unseren CD Laufwerk. Jetzt kann die Installation des Gasts erfolgen, abschliessend trennen wir wieder das CD Image und ändern die Bootreihenfolge auf HD.
In einem anderen Post werde ich auf eine automatisierte Variante zum Bauen der Gäste eingehen.

Referenzen:

  • http://blog.gadi.cc/better-lvm-for-kvm/