blog · git · desktop · images · contact & privacy · gopher


overqemu

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:

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.