blog · git · desktop · images · contact
2013-12-15
– Nachtrag 2020-12-13: Umgezogen:
https://uninformativ.de/git/overqemu
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:
/tmp
“
abgelegt. „/tmp
“ ist bei mir ein tmpfs. Bei darauffolgenden
Starts wird dieses Image weiterbenutzt.22xx
“, wobei die „xx
“
durch die zweistellige Slot-ID ersetzt werden. Die Slots gelten
global, es gibt insgesamt 100 Stück.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.