Es wäre gelogen wenn ich sagen würde, das ich "immer wieder" in die Situation gelange KVM Hosts zu bearbeiten oder zu migrieren. Dennoch ist KVM ein toller Hypervisor der sowohl Spaß macht, als auch interessante Features mit sich bringt und gleichzeitig vom Handling her den Eindruck vermittelt vieles noch handhaben zu können, auch wenn es mal zu dicken Schwierigkeiten kommt.
Daher habe ich für mein Setup ein Skript gebastelt, welches mir die Konfigurationen (XML - Daten) der eingerichteten virtuellen Maschinen mittels virsh exportiert um im falle eines Ausfalls die Maschinen wieder rekonstruieren zu können (mit wirsch define oder wirsch create).
Wichtig dafür ist natürlich das es ein externes Medium gibt auf dem die Daten gespeichert werden können. In meinem Fall ist es ein zentrales FreeNAS Storage.
Wenn man noch zwischen unterschiedlichen Linux Distributionen hin- und her switched hat man unter umständen das Problem, dass bestimmte Maschine types nicht vorhanden sind oder andere Werte angepasst werden müssen. Dazu nutze ich einfach "sed" das mir unter die Arme greift.
Als Ergebnis habe ich mittels Cron alle voll Stunde frische Konfigurationsdateien die ich einfach auf einem anderen KVM Host importieren kann.
Mit Hilfe meines Skript kann ich nun mit Hilfe von Parametern sowohl alle virtuellen Maschinen an ohne Angabe eines Parameters an einen in "CONFIGDESTDIR" definiertenOrt speichern, oder diesen angeben.
Beim Import verhält es sich ein wenig anders. Hier kann ich zusätzlich noch eine bestimmte Maschine angeben
#!/bin/bash
CONFIGDESTDIR=/PATH/TO/STORAGE/
if [ "$1" == "export" ]; then
if [ -z "$2" ]; then
echo "Konfigurationen werden nach $CONFIGDESTDIR exportiert!";
else
CONFIGDESTDIR=$2
echo "Konfigurationen werden nach $CONFIGDESTDIR exportiert!";
fi
if [ -d $CONFIGDESTDIR ]; then
echo "Exportverzeichnis ist vorhanden.";
else
echo "Exportverzeichnis ist nicht vorhanden und wird angelegt!";
mkdir $CONFIGDESTDIR;
fi
for i in $(virsh list --all | sed '1,2d' | awk '{print $2}')
do
VMNAME=$(basename $i .xml)
virsh dumpxml --migratable $VMNAME > $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/\/usr\/bin\/kvm/\/usr\/libexec\/qemu-kvm/" $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/machine='pc-1.1'/machine='pc-i440fx-rhel7.0.0'/" $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/machine='pc-0.12'/machine='pc-i440fx-rhel7.0.0'/" $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/type='vmvga'/type='vga'/" $CONFIGDESTDIR/$VMNAME.xml;
done
fi
if [ "$1" == "import" ]; then
if [ -z "$2" ]; then
echo "Konfigurationen werden aus $CONFIGDESTDIR importert!";
else
CONFIGDESTDIR=$2
echo "Konfigurationen werden aus $CONFIGDESTDIR importert!";
fi
if [ -d $CONFIGDESTDIR ]; then
echo "Importverzeichnis ist vorhanden.";
else
echo "Importverzeichnis ist nicht vorhanden!";
exit;
fi
if [ -z "$3" ]; then
echo "Es werden alle Maschinen importiert!";
for i in $(ls $CONFIGDESTDIR/*.xml)
do
echo "Definiere Maschine $i";
virsh define $i;
echo "Richte Autostart ein fuer: $i";
virsh autostart $i;
done
else
echo "Definiere Maschine $3";
virsh define $CONFIGDESTDIR/$3;
echo "Richte Autostart ein fuer: $3";
virsh autostart $CONFIGDESTDIR/$3;
fi
fi
Es gibt viele Wege die nach Rom führen. Das gilt auch in Landschaften für virtuelle Infrastrukturen. Was einem heute noch gefallen mag, ist morgen nicht mehr praktisch.
Wie in vielen Dingen ist es bei Lösungen unter Linux nicht gegeben, dass man ein oder zwei Wege zur Auswahl hat, sondern mehrere. In vielen fällen wird geraten VMs auf LVM (Logical Volume Manager) Basis mit RAW Festplatten auszustatten. Das ist in sofern richtig, dass weniger Abstraktionsschichten auch bedeuten dass es weniger zu verwalten gibt und daher auch meist schneller ist.
Im Vergleich zu dem KVM (qemu) eigenen QCow2 Format gibt es seit jeher Messungen, Messungen, Diskussionen und Vergleiche was denn nun das beste sei. Ich denke, das ab einem gewissen Grad an vorhandener Grundleistungen die Zahlen kaum noch das reale Empfinden bei der Arbeit mit den Maschinen widerspiegeln - gesonderte Ausnahmen selbstverständlich aussen vor.
Allerdings hat man mit Images auf Dateibasis den Vorteil der Flexibilität auf seiner Seite. Mitnehmen, verschieben, zwischen den Maschinen migrieren - alles langweilig, weil einfach.
Wenn man nun diesen Weg gehen möchte, muss das, was bisher als logical Volume vorlag in ein Image umgewandelt werden. Dazu habe ich mir dieses einfach Skript überlegt und getestet. Wichtig ist, dass alle umzuwandelnden Disks in einer Volumegroup liegen. Hat man sich für eine Namenskonventions der Laufwerke entschieden kann diese nachträglich eingebaut werden. Will man die Dateien und Laufwerke manuell angeben kann das Skript ebenfalls sehr einfach angepasst werden.
Sobald alles durchgelaufen ist, hat man seine Images unterhalb des Verzeichnisses, dass in der Variablen $STORE angegeben ist.
Natürlich kann man noch 1000 Features einbauen. Für mich hat es allerdings gereicht um eine Umgebung für den Umzug vorbereiten zu können.
Wichtig: Nach der Umwandlung die Konfiguration der virtuellen Maschine anpassen, sodass die neue Festplatte genutzt wird. Das passiert üblicher Weise in der Datei /etc/libvirt/qemu/VMNAME.xml
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='PFAD-ZUM-IMAGE.qcow2'/>
Wenn man seine virtuelle Infrastruktur mit KVM betreibt, so hat man es nicht leicht. Viele Möglichkeiten und eine fast besser als die andere. Perfomantes LVM RAW Device für die Festplatten gegenüber dem flexiblem QCow2 zum mitnehmen und leichten ablegen/bewegen der Images.
Im grunde genommen spielt es vermutlich kaum eine rolle welche der vielen Möglichkeiten man für sich entdeckt - die Einfachheit hat auch hier wieder eine Lösung für den Fall das man sich mittendrin anders entscheidet.
Wenn man beispielsweise seine VM von einem Debian mit LVM/RAW auf ein CentOS mit QCow2 umziehen möchte, so geht das folgendermaßen:
Grundsätzlich empfiehlt es sich nicht allzu viele Sonderlocken einzubauen und sich möglichst nah am Standard zu bewegen, damit die kompatibilitäten innerhalb der Systeme gegeben sind.
Happy migrating!