Libvirt QEMU/KVM VM migration/upgrading

Wenn man VMs (und deren Definitionsdatei) von einem älteren KVM System umzieht oder den Hypervisor upgraded sollte man nicht vergessen im XML-file den Maschinentyp zu checken. Ansonsten kann es nach Live-Migrationen zu unerwarteten Effekten kommen. Bei mir hing z.B. bei einigen Systemen die Real-Time-Clock – was oft einen Totalabsturz zur folge hat. Der Bug ist hier beschrieben.

Für eine aktuelle QEMU-KVM Version sieht dies so aus (entscheidend ist das „pc-1.0“):

<!-- /etc/libvirt/qemu/vm-01.xml -->
<type arch='x86_64' machine='pc-1.0'>hvm</type>

Damit man nicht händisch sämtliche XML Dateien anpassen muss, liefert Libvirt ein praktisches, aber wohl eher unbekanntes Script mit:

libvirt-migrate-qemu-machinetype -a

Damit werden direkt alle VMs auf die jeweils aktuelle Einstellung angepasst. Sehr schön. Damit die Einstellung greift muss man die VMs allerdings neu starten (soweit ich weiß).

libvirt: Interface hinzufügen

Einfacher und eleganter als das XML zu editieren und dann zu reloaden ist direkt das Interface (in diesem Fall ein Bridge-Device) über libvirt hinzuzufügen:

virsh attach-interface domain-1-22 bridge br0

libvirt: XML neu einlesen

Damit liest libvirt die entsprechende Beschreibungsdatei (ohne Neustart von libvirtd) erneut ein:

virsh define /etc/libvirt/qemu/domain-1-22.xml

Centos neben Ubuntu, Launchpad & Co.

Langsam stehen einige Major-(Web-)Serverupdates an und ich überlege mittlerweile ernsthaft von Centos/RHEL auf Ubuntu Longterm umzusteigen. Auf dem Desktop habe ich Ubuntu schon lange, aber auch im Serverbereich möchte ich es mittlerweile an einigen Stellen nicht mehr missen. Nicht das ich besonders unzufrieden mit Centos/RHEL wäre. Eigentlich gar nicht. Es sind nur so ein paar Dinge die mich immer wieder zum Nachdenken bewegen:

Releasezyklus. Centos 5 ist bei Kernel 2.6.18, php 5.1, mysql 5.0. Klar, in den Centos Kernel werden viele wichtige Features gebackported. Wie z.B. letztens bei Centos 5.4 die virtio-Unterstützung für KVM. Nativ gab es diese aber schon im 2.6.24 (Januar  2008). Wann Centos 6 kommt steht noch in den Sternen (sehr wahrscheinlich jedoch dieses Jahr). Ubuntu hat einen festen Releasezyklus und ich wusste schon seit vielen Monaten dass Ende April die neue Long-Term Version erscheint. Also zumindest gut planbar.

Major-Relase Updates. Mit yum als Paketmanager gibt es (meines Wissens) keinen offiziellen Weg. Apt hat kein Problem damit.

Support. Vorteil Centos: Viele große Hardwarehersteller unterstützen RHEL mit Treibern. Da Centos Binary-Compatible ist profitiert man also davon. Docs/Community: Mag lächerlich klingen: Meistens muss ich doppelt googlen: Erst nach „centos“ dann nach „rhel“. Ubuntu hat eine gebündelte Community. Launchpad tut das übrige (s.u.).

Externe Repositories. Klar, für Centos gibt es auch irgendwo alles. Sei es neuere snmpd-Versionen oder syslog-ng. Aber halt meistens an verschiedenen Stellen. Was ich an Ubuntu sehr genial finde ist Launchpad. Launchpad hat mit Sicherheit einen großen Anteil am Erfolg Ubuntus. Es ist quasi alles in einem: Bugtracker, Mailingliste, Build-System und vor allem Repository. Und am Rande erwähnt: Mit einer vorbildlichen Usability und Optik ;). BTW: Launchpad lässt sich nicht nur für Ubuntu-Projekte nutzen.

Eines ist mir wohl bewusst: Einen klaren Sieger gibt es niemals. Es ist immer nur eine Abwägung und letztendlich eine eher subjektive Entscheidung. Wie schon anfangs erwähnt laufen einige Management-Maschinen unter Ubuntu. Sei es iSCSI, drbd oder das neueste von KVM – es hat schon Vorteile problemlos mit aktuellen Versionen arbeiten zu können…

Ob dieser Schritt letztendlich auch für die Masse der Webserver genommen wird ist noch nicht entschieden. Denn eines ist auch klar: Centos hat dort noch nie enttäuscht und das neueste vom neuen brauche ich dort eigentlich nicht. Aber eine neuere PHP oder MySQL Version wäre andererseits doch schön… So ist es halt: Never ending story…

Bleeding Edge of KVM Virtualization

Was ich immer schon mal schreiben wollte: Seit ein paar Monaten hilft mir das Repository von Daniel Baumann das jeweils neueste aus der qemu-kvm Welt (produktiv) unter Ubuntu zu nutzen. Daneben gibt es auch aktuelle Versionen von libvirt und virt-manager.

Beeindruckend stabil das ganze.

VDSL & Astaro at Home

Lange habe ich nach einem geeigneten Router für meinen VDSL Anschluß (ohne Entertain) gesucht.

Zunächst wollte ich einfach meinen Linksys WRT54GL (OpenWRT) nehmen. Leider habe ich nur wiedersprüchliche Infos bzgl. 802.1q Tagging auf der WAN Schnittstelle gelesen. Ausserdem gab es keine zuverlässigen Infos über die Perfomance:  die 50MBit/s erreicht er wohl nur mittels übertakten.

Letztendlich bin ich jetzt (wieder) bei meinem VDR-Server gelandet: In einer Virtuellen Maschine (KVM) läuft jetzt allerdings die Software-Firewall Astaro. Die Homelizenz erlaubt es seit kurzem, 50 IPs für den Heimgebrauch zu Routen. Natürlich kann man sicherlich auch eine andere Firewalldistribution nehmen. Da ich von der Astaro aber aus dem kommerziellen Umfeld überzeugt bin, stellte sich die Frage nicht ;).

Astaro

Also eine 2. Netzwerkkarte in den VDR, installation in der KVM angeschmissen, VDSL-Zugangsdaten eingegeben – IPSec, PPTP, SSL VPN eingerichtet – alles problemlos.

Mein armer OpenWRT Router läuft jetzt nur noch als WLAN AccessPoint.

Noch ein Hinweis zum VLAN Tagging aus der KVM heraus: Zuverlässig scheint dies erst ab kvm-84 zu klappen. Für Debian gibt im Backports-Repository die nötigen Pakete.