Projekt »Virtueller hochverfügbarer Linux-Server«, Teil 7
Prozessor-Upgrade, neues Xen und neue Ideen
Andere Image-Formate
Ende 2007 stieß ich auf ein neues Problem. Das Kopieren von großen Dateien (100 MB bis einige GB) von einem Client in eine virtuelle Maschine (domU) führte zu einer Kernel-Panic auf dem Host (dom0). Danach war das XFS-Dateisystem der domU beschädigt und musste repariert werden.
Vermutlich handelt es sich bei dem Problem um einen Fehler, der in neueren Kerneln längst behoben ist. Xen baut jedoch dummerweise weiterhin auf Linux 2.6.18, und ein Update von XFS oder des Netzwerktreibers erschien mir nicht realistisch. Ich begann mir deshalb einmal KVM anzusehen.
KVM setzt ein leicht modifiziertes Qemu als Userspace-Komponente ein. Qemu kann verschiedene Image-Formate für seine virtuellen Laufwerke verwenden. Es bietet jedoch keine Möglichkeit, ein Image einer einzelnen Partition einzubinden, so wie viele Xen-Anleitungen das angeben. Meine Xen-Installation konnte also nicht direkt in eine KVM-Installation umgewandelt werden.
Weniger bekannt ist, dass Xen auch andere Image-Formate beherrscht, insbesondere kann es ganze Festplattenimages z.B. in den Formaten »raw« und »qcow2« verwenden, die beide auch von Qemu genutzt werden können. Hätte ich das früher gewusst, hätte ich für Xen gleich einen anderen Ansatz gewählt.
Nun wollte ich wissen, wie Xen mit anderen Image-Formaten funktioniert. Denn ich musste sowieso den Plattenplatz der einen oder anderen domU vergrößern. Dazu wollte ich ein neues, ausreichend großes Image anlegen, in die domU einbinden und die Daten darauf kopieren. Dies hätte einen nahezu unterbrechungsfreien Betrieb ermöglicht mit der Option, später schmerzlos zu KVM zu wechseln.
Ich hatte noch genug Reserve, um eine weitere Partition mit LVM anlegen zu können. Diese formatierte ich mit XFS, dann legte ich ein Image im qcow2-Format an. Das Image ist anfänglich nur wenige KB groß, es wächst nach Bedarf bis zur Höchstgrenze.
mkfs.xfs /dev/mapper/test mount /dev/mapper/test /mnt/tmp qcow-create 3000MB /mnt/tmp/test.image
Zuvor hatte ich ein bestehendes Qemu-Image kopiert und versuchte dieses einzubinden. Die ernüchternde Erkenntnis daraus war, dass Xen nicht jedes Image im qcow2-Format lesen kann. Solche, die mit qcow-create erzeugt wurden, funktionieren aber.
Man kann Laufwerke in eine laufende domU einbinden, ohne dass die domU unterbrochen werden müsste. Dies funktioniert mit dem Kommando xm block-attach:
xm block-attach 2 tap:qcow:/mnt/tmp/test.image /dev/xvda w 0
Dabei ist 2 die ID der domU, /dev/xvda ein Gerätename, der anscheinend frei gewählt werden kann (auch /dev/sdb oder anderes wäre möglich), w steht für Schreibzugriff und die 0 am Ende ist bedeutungslos. Eine Liste der eingebundenen Geräte kann man mit xm block-list 2 sehen, und entfernt wird ein Gerät mit xm block-detach 2 [Device-ID]. Interessanterweise kann man ein Gerät auch der dom0 zuweisen und so z.B. testen, ob es Geschwindigkeitsunterschiede zwischen dom0 und domU gibt.
Da das Gerät in der VM, der es zugewiesen wurde, als »Laufwerk« erscheint, partitionieren wir es mit fdisk und legen in der Partition wiederum ein Dateisystem an, z.B. XFS. Danach mounten wir das Dateisystem. Die Geschwindigkeitstests, deren genaue Ergebnisse ich nicht aufgehoben habe, ergaben ein verheerendes Bild: Die Geschindigkeit solcher Images ist nicht einmal 1% der normalerweise erwarteten Geschindigkeit. Im Falle von qcow-Images ist dies teilweise sogar zu erwarten, denn jedesmal, wenn mehr Platz gebraucht wird, wird die zugrundeliegende Datei vergrößert, wobei offenbar bei jedem Block eine Sync-Operation durchgeführt wird.
Ich testete daher auch mit einem Raw-Image, doch das Ergebnis blieb fast gleich. Auch andere Dateisysteme sowohl in dom0 als auch in domU änderten nichts. Ich kann daraus nur den Schluss ziehen, dass der blktap-Treiber, der in Xen für diese Images verantwortlich ist, momentan unbrauchbar ist.
In diesem Zusammenhang führte ich noch einen anderen Test durch. In der Konfigurationsdatei einer VM werden die Partitionen folgendermaßen definiert:
disk = [ 'file:/mnt/vm100/vm100.image,sda1,w', 'file:/mnt/vm100/swap.image,sda2,w' ]
