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 ist mir schon immer ein Rätzel gewesen, weshalb alle Welt verrückt nach "Internet-Security-Suiten" zu sein scheint. Jedenfalls gibt es einen riesigen Markt dazu und Endbenutzer vermuten einen persönlichen Bodyguard dahinter.
Ganz falsch ist das zwar nicht. Allerdings muss man auch ehrlich sein und zugeben, dass ein Bodyguard nichts macht, wenn der Chef sich dämlich verhält.
Wie dem auch sei: Für Firmen und Rechner macht es durchaus Sinn seine Daten und Zugriffe gegen potentielle Gefährdungen zu schützen - ich sehe das wie ein "Vier-Augen-Prinzip". Dumm ist es nur, wenn hierbei die Software nicht mit Spielt.
Mittlerweile ist es für mich die erste Anlaufstelle den Virenscanner bei Problemen zu deaktivieren um zu schauen, ob sich das gewünschte Verhalten einstellt. Zuletzt habe ich diverse Lösungen auf meinem Mac ausprobiert und wunderte mich über deren "Nichtfunktionieren". Es stellte sich heraus, das Apple mit El Capitan eine (sinnvolle) Erweiterung integriert hat, welche sich SIP (System Integrity Protection) - oder kurz rootless - nennt.
Diese scheint jedoch - wie vieles das man "mal eben so" integriert den Anbietern von Drittsoftware einiges an Schwierigkeiten zu bereiten. Zumindest ist das Netz ziemlich voll davon.
Abhilfe schafft folgendes:
Sicherlich ist das nicht die tollste aller Lösungen, aber wenn es nicht anders geht, dann geht es nicht anders.
Über die selben Schritte kann man es auch wieder aktivieren - nur eben mit einem csrutil enable zum Schluss.
Quellen:
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'/>