Annahmen
Beim LVM wird angenommen, dass es ein VG gibt, in dem alle LVs die zu den virtuellen Machinen gehören, gibt. Jedes LV ist direkt ein Laufwerk für die virtuellen Maschinen. Diese wird hier virtlvm genannt.
Es wird angenommen, dass es 2 Maschinen gibt. Eine Maschine - der Host, auf dem libvirt aufgesetzt werden soll und auf der kein X zur Verfügung steht und eine zweite Maschine - der Client, von der aus man sich mit dem Host verbindet. Zusätzlich gibt es noch die virtuellen Maschinen - VMs - die virt1, virt2… genannt werden.
Prinzipiell funktioniert libvirt auf allen möglichen Distributionen. Hier wird dennoch nur von Ubuntu 12.04 ausgegangen. Bei Debian wird es sicher exakt genauso funktionieren.
Installation
libvirtd und qemu installieren. Zweiteres ist keine Abhängigkeit von ersterem, weil libvirtd nicht nur qemu unterstützt.
sudo apt-get install libvirtd kvm-qemu # Ubuntu
System Einrichten
Ausser libvirtd muss auch das System korrekt eingerichtet werden.
LVM2 einrichten
Damit die Platten der virtuellen Maschinen nicht vom Host angegriffen werden und deren LVM unberührt bleiben,
muss man den filter in der /etc/lvm/lvm.conf
anpassen:
# All devices named dm-* and all devices in subdirs of /dev will be rejected.
# Every device else in /dev will be accepted.
filter = [ "r|^/dev/dm-*|", "r|^/dev/.*/|", "a|^/dev/.*|" ]
Beim nächsten Neustart wird dennoch das VG vom Host erkannt. Dagegen hilft nur ein Neuerstellen der Initramfs (hier für jeden Kernel):
sudo update-initramfs -k all -c # Ubuntu
Administrationsbenutzer einrichten
Es ist nicht nötig, immer als root
die Administration der virtuellen Maschinen vorzunehmen. Besser ist es, wenn der typische Benutzer dazu berechtigt wird.
sudo usermod -aG libvirtd <YOU>
In Kombination mit ssh wird dadurch auch die Migration auf anderen Maschinen erleichtert.
Mehrere Maschinen und Migrationen
Um die Migration von einer Maschine zur Anderen unterstützen zu können, hilft ssh und um sich die Eingabe der Passphrase zu ersparen helfen Schlüssel. Schlüssel sind sicherer als Passphrase, solange die Maschinen sicher sind. Ist eine unberechtigte Person auf der Maschine mit dem Benutzer, kann er auch evenutell die Schlüssel missbrauchen, wenn diese nicht Passphrasegeschützt sind. Es ist zu empfehlen ein Passphrase auf den Schlüssel zu setzen, dann ist allerdings wieder die Passphrase nötig, die eigentlich gespart werden sollte. Aber auch hierfür gibt es eine Lösung mit dem ssh-agent, aber somit wird es wieder möglich, wenn eine unberechtigte Person auf diese Maschine kommt, kann er den Schlüssel missbrauchen. Allerdings hilft ihm das kopieren des Schlüssels nichts mehr.
Daher sind Schlüssel mit Passphrase und ssh-agent ein guter Kompromiss. Mehr Sicherheit bekommt man nur, wenn man den ssh-agent weglässt.
Zuerst den ssh-agent und keychain installieren um in jeder Konsole so schnell wie möglich auf den Schlüssel zugriff zu erhalten:
sudo apt-get install keychain # Debian based
echo 'eval `keychain --eval --quiet`' | sudo tee /etc/profile.d/keychain.sh # ssh-agent beim einloggen sofort aktivieren.
Schlüssel:
ssh-keygen # Schlüssel generieren und bitte Passphrase nicht vergessen!
ssh-copy-id <YOU@OTHERMACHINE> # Schlüssel auf die andere Maschine kopieren.
Sollte man nach der Passphrase des Schlüssels gefragt werden, ist der Schlüssel ssh-agent noch nicht bekannt. Dies kann man mit hiermit erreichen und danach braucht man es nicht mehr einzugeben:
ssh-add # Passphrase des Schlüssels wird abgefragt.
Wichtig : Auf keinen Fall ssh und root kombinieren! Niemals als root sich via ssh anmelden.
Bridge
Bei statischen IP-Adressen wird folgende Config wie folgt um bridge_*
-Einträge erweitert:
auto br0
iface br0 inet static
address IPADDRESS
netmask IP
network IP
broadcast IPN
gateway IP
dns-nameservers NAMESERVERS
bridge_ports eth0
bridge_stp off
bridge_maxwait 5
Bei dynamischen IP-Adressen entsprechend mit dhcp. eth0
muss durch das entsprechende Device geändert werden.
Die NICs der virtuellen Maschinen nicht bei bridge_ports
aufzählen, die werden durch libvirtd automatisch hinzugefügt.