overqemu

2013-12-15

– Nachtrag 2020-12-13: Umgezogen:

Dort liegt jetzt auch die Doku und nicht mehr – wie am Ende des Blogposts erwähnt – im Gopher-Space.

Seit einigen Monaten habe ich immer wieder die Situation, dass ich eine VM brauche, dort nur kurz etwas machen will und die VM dann eigentlich wieder wegschmeißen kann. Außerdem habe ich nach vielen Jahren dann doch mal einen neuen Rechner gekauft, wodurch Virtualisierung insgesamt wieder viel interessanter geworden ist, weil jetzt Hardware-Virtualisierung richtig gut funktioniert und viel RAM vorhanden ist. Ich kann jetzt endlich bedenkenlos mehrere VMs gleichzeitig laufen lassen. Auf der anderen Seite habe ich eine SSD, die ich schonen möchte.

QEMU, das mit KVM ziemlich performant und gleichzeitig leichtgewichtig ist, bringt von Hause aus die Option „-snapshot“ mit. Dadurch wird das Festplattenimage überhaupt nicht angefasst, es sei denn, man setzt ausdrücklich einen „commit“ ab. Das ist schon einmal nicht schlecht. Der Default hierbei ist dann, dass nach dem Herunterfahren der VM alles weg ist. Problem: Ich weiß gar nicht, ob ich das will. Vielleicht will/muss ich die VM mal zwei Stunden ausschalten und dann später damit weitermachen – aber immernoch will ich das Basis-Image nicht anfassen.

Hier kommt jetzt overqemu ins Spiel. Das Skript tut folgendes:

Beim ersten Mal wird ein Overlay-Image erstellt und in „/tmp“ abgelegt. „/tmp“ ist bei mir ein tmpfs. Bei darauffolgenden Starts wird dieses Image weiterbenutzt.
Automatische Einrichtung von Portforwardings für SSH oder mehr.
Organisation in „Slots“: Dasselbe Basis-Image kann mehrfach gestartet werden. Dabei werden Portforwardings automatisch angepasst. SSH-Ports haben also die Form „22xx“, wobei die „xx“ durch die zweistellige Slot-ID ersetzt werden. Die Slots gelten global, es gibt insgesamt 100 Stück.
VNC als Display, damit bei Bedarf direkt auf die VM zugegriffen werden kann.
Noch ein kleines bisschen Unterstützung bei der Erstellung von QEMUs Multicast-Socket-Netzwerken, weil die eine sehr einfache Möglichkeit darstellen (lies: keine weitere Einrichtung oder Root-Rechte auf dem Host nötig), um VMs miteinander kommunizieren zu lassen.
Als Alternative ist auch Support für TAP-Interfaces drin, damit eine VM auch ein vollwertiges Interface bekommen kann. Falls man eine Bridge will, damit die VM auch von anderen Hosts aus erreichbar ist, muss man diese aber manuell anlegen. TAP-Interfaces habe ich bis jetzt aber sehr selten tatsächlich gebraucht, noch seltener als Multicast-Socket-Netzwerke.

Es ist damit sehr leicht, zum Beispiel zehn Instanzen von Arch zu starten:

for i in {1..10}; do overqemu -b ~/VMs/archlinux-dhcp.qcow2 $i & done

Das „-b“ zeigt standardmäßig auf dieses Image. Soll zusätzlich noch Port „80xx“ an die VM weitergeleitet werden, wobei das „xx“ hier wie bei den SSH-Ports durch die Slot-ID ersetzt wird:

for i in {1..10}; do overqemu -f 80xx:80 $i & done

Oder alle VMs in ein Multicast-Netzwerk, damit sie sich sehen können (erzeugt eine zusätzliche NIC – Portforwardings auf die erste NIC wären weiterhin möglich):

for i in {1..10}; do overqemu -m 230.0.0.1:1337 $i & done

„-m“ geht auch mehrfach. Es ist auch wichtig zu erwähnen, dass auf einem anderen Host dasselbe Multicast-Netzwerk konfiguriert werden kann. Die VMs sehen sich dann, sofern kein Router dazwischensitzt, der Multicast verwirft – was im Internet die Regel ist, man hat zuhause also seine Ruhe.

In diesen Fällen würde ich tatsächlich die Overlay-Images wegschmeißen wollen. Oder? Vielleicht auch nicht. Vielleicht ergibt sich in einer VM etwas, das ich behalten möchte. Dann kann ich diese VM ausschalten, das Overlay-Image rebasen und somit eine neue VM/Festplatte erstellen, in die ich die Änderungen dann dauerhaft committen kann:

cd /tmp
cp ~/VMs/archlinux-dhcp.qcow2 arch-neu.qcow2
qemu-img rebase -b arch-neu.qcow2 overqemu-00.qcow2
qemu-img commit overqemu-00.qcow2

Die neue VM liegt weiterhin in „/tmp“, bis ich mich dann irgendwann mal entscheide und sie tatsächlich auf die SSD zur dauerhaften Aufbewahrung kopiere.

Das finde ich schon ziemlich fancy. :-)

Die vielen verfügbaren Slots zahlen sich auch aus. Natürlich starte ich keine 100 VMs auf einen Schlag. Aber ich weiß, dass ich genügend Platz habe – anfangs konnte das Skript nur mit 10 Stück umgehen, was von der Gesamtzahl auch gereicht hätte, aber da fühlt man sich ja immer gleich so eingesperrt. Das ist wie mit den Zeilennummern im alten BASIC. Jetzt aber habe ich immer Luft. Wenn ich bei irgendwas unterbrochen werde und noch eine VM brauche, dann kann ich sie ohne nachzudenken starten.

Weitere Notizen für overqemu habe ich drüben im Gopher-Space.

Comments?