Virtuelle Maschinen in Debian-Paketen

Eine virtuelle Maschine (VM) unter Xen besteht aus mehreren Dateien: einer Xen-Konfigurationsdatei, die in der Regel in /etc/xen liegt und den Namen der Domain trägt, sowie aus Container-Dateien, die die virtuelle(n) Festplatt(en) darstellen. Der Ansatz eine VM in einem Debian-Paket zu verpacken, hat einige Vorteile: Die Dateien bleiben zusammengehörig, sodass sie sich leicht aus dem System entfernen lassen und nicht als "Leichen" rumliegen. Beim Einrichten einer VM können die Maintainer-Skripte und die Debian-Konfigurationsmechanismen die Vorkonfiguration der VM übernehmen, etwa Passwörter setzen und Adressen einstellen. Der c't-Debian-Server bringt die Endian Firewall und ClarkConnect in dieser Form mit.

Der Grundaufbau der Pakete ist stets gleich. Sie bringen eine VM-Konfigurationsdatei mit, die in /etc/xen landet. Die Dateisystemimages liegen in /var/lib/xen/vmname. In den Namen ist der Verwendungszweck und die Zielgröße kodiert. Das postinst-Skript nutzt diese Informationen, um die Dateien entweder zu vergrößern oder sie auf entsprechend dimensionierte LVM-Volumes aufzuspielen. Landen die virtuellen Platten auf LVM-Volumes, dann setzt das postinst-Skript die Dateigröße in /var/lib/xen/vmname auf Null. Die Dateien bleiben als Verweise für die Deinstallation erhalten. Die Dateien enthalten letztlich einen Schnappschuss einer Grundinstallation des jeweiligen Betriebssystems.

Kein Licht ohne Schatten: Um den Platzbedarf bei der Installation der VMs klein zu halten, sind die im komprimierten Debian-Paket enthaltenen Dateien nochmals komprimiert. Sie werden erst beim Übertragen auf ein LVM-Volume entpackt beziehungsweise als Datei auf volle Größe entfaltet. Der Vorgang ist -- je nach Hardware -- nicht gerade schnell. Die Pakete fallen sehr voluminös aus.

Der nahe liegende Gedanke, dass die Verpackung als Debian-Paket Updates erleichtern würde, geht leider nicht auf: Diese Updates würden mindestens so groß, wie das Originalpakt -- das ist aber nicht erstrebenswert. Würde man im Update-Paket die blähenden Image-Dateien weglassen, wäre die aktuellste Version des Pakets nicht mehr in der Lage eine funktionstüchtige VM zu installieren. Hier wäre evtl. die Aufteilung in mehrere von einander abhängige Pakete zu diskutieren, etwa die Ausgliederung in ein reines Image-Paket ... Bis dahin gibt es eben speziell benannte Update-Pakete, wie für ClarkConnect clarkconnect-update, statt neuer Versionen unter dem Namen des ursprünglichen Pakets.