Beim Aufsetzen eines neuen Servers schlage ich zur Zeit einen Weg ein, bei dem bestimmte Serveraspekte in virtuellen KVM-basierten Maschinen gekapselt werden sollen. Nun nutze ich auf dem KVM-Host als Basis einer flexiblen Partitionierung LVM. Die virtuellen KVM-Systeme erhalten ihre virtuellen Platten und zugehörige Partitionen in Form der Zuweisung von logischen LVM-Volumes, die auf dem KVM-Host vorliegen. Der Zugriff des Gastes auf dieses Raw-Device erfolgt in meinem Fall über “virtio”. Im Zuge der Installation des Gast-Systemes werden innerhalb der virtuellen Harddisk dann “virtuelle” Partitionen des Gastsystems angelegt. Die nachfolgende Darstellung illustriert dies:
Aufgabenstellung: Mounten virtueller Partitionen eines KVM-Gastes auf dem KVM-Host
Der Inhalt der Aufgabenstellung hört sich nur scheinbar widersprüchlich an. Es kann tatsächlich mal vorkommen, dass man aus bestimmten Gründen gerne vom Host aus auf eine der “virtuellen” Partitionen des KVM-Gastes zugreifen möchte. Natürlich nur, wenn das KVM-Gastsystem nicht aktiv läuft und die virtuelle Harddisk nicht vom Gastsystem genutzt wird.
Bei ein wenig Nachdenken wird sofort klar: Ein solcher Zugriff des KVM-Hostes erfordert ein zwischengeschaltetes Tool – in den Partitionsverzeichnissen des Hosts wird die virtuelle Partition eines Gastes, die sich innerhalb eines logischen LVM-Volumes befindet, nicht direkt als mountbares Device bereitstehen. Die Situation ist hier vergleichbar mit der internen Struktur von Files, die als Loopback-Devices genutzt und gemountet werden. Der YaST2-“Partitioner” des Opensuse 12.3-Systems etwa lässt die interne Partitionierungs-Struktur logischer LVM-Volumes nicht erkennen. Schließlich wird ja das gesamte logische LVM-Volume von KVM als Raw-Device behandelt und enthält keine unmittelbaren Filesystem-Informationen wie eine normale formatierte (LVM-) Partition des Hosts.
Gründe für einen Zugriff auf virtuelle Partitionen der KVM-Gastsysteme vom Host aus können vielfältig sein – u.a. sind zu nennen:
- Erstellung von Sicherungen bestimmter Inhalte des Gast-Filesystems.
- Bearbeitung bestimmter Files des Filesystems des KVM-Gastes auch bei nicht laufendem KVM-Gast.
In meinem Fall hatte ich eine Konfigurationsdatei das Gastes verpfuscht, die ein normales Starten dieses KVM-Gastes verhinderte. Diese Datei hätte ich nun gerne vom Host aus bearbeitet, um das Gastsystem ohen Rückgriff auf Sicherungen wieder zum Laufen zu bringen.
Lösung: kpartx
Gibt es nun ein Linux-Tool mit dem man die Struktur des Raw-Devices auslesen und die Partitionen erkennen kann ? Ja, das gibt es – es heißt “kpartx”. Ich zitiere aus der zugehörigen “man-page”:
Name : kpartx – Create device maps from partition tables
Synopsis : kpartx [-a | -d | -l] [-v] wholedisk
Description : This tool, derived from util-linux’ partx, reads partition tables on specified device and create device maps over partitions segments detected. It is called from hotplug upon device maps creation and deletion.
“kpartx” kann man für verschiedene Devices oder Platten-Images einsetzen. Neben der Bereitstellung interner Partitionen von Raw-Device-Harddisks für virtuelle KVM-Systeme eignet es sich z.B. auch für den Zugriff auf Loopback-Device-Files.
Die verschiedenen Optionen von “kpartx” sehe man sich selber an. Mittels der Option “-a” erzeugt man eine vollständige Liste der Partitionen eines Raw-, LVM- oder Loopback-
Devices im Verzeichnis:
/dev/mapper
Die dortigen Einträge entsprechen unter Opensuse Links übrigens Devices der Form “/dev/dm-xx”. Diese Devices kann man dann im KVM-Host benutzen und u.a. mounten.
Ein Beispiel
Nachfolgend zur Illustration ein paar typische Kommandos für ein Testsetup:
Das Harddisk-Array der Testmaschine ist ein Raid 10-Array aus vier 2 TB-Platten. Das Array wurde mit GPT partitioniert. Die bislang aufgesetzten logischen Volumes befinden sich unter “/dev/volgrp1”. Einem virtuellen KVM-Gast wurde u.a. das logische Volume “/dev/volgrp1/vm_imap_hd0” als virtuelle Harddisk per virtio-Treiber zur Verfügung gestellt und beim Installieren des Betriebssystems OS 12.3 mit 2 “virtuellen” Partitionen – einem Swap-Bereich und einer ext4-Partition – ausgestattet.
Folgender Screenshot liefert einen Überblick:
Man erkennt, dass “fdisk” und “parted” den internen Aufbau z.B. des logischen LVM-Volumes “/dev/volgrp1/vm_imap_hd0” durchaus erkennen. Allerdings finden sich unter “/dev/mapper” noch keine entsprechenden Devices, die im Host direkt brauchbar und mountbar wären.
Hierfür benötigen wir nun den Befehl “kpartx” in der Form
kpartx -a /dev/volgrp1/vm_imap_hd0
Es wird klar, dass “kpartx -a /dev/volgrp1/vm_imap_hd0” denn internen Aufbau des logischen Volumes analysiert und entsprechende Devices unter “/dev/mapper” bzw. in unserem Fall als “/dev/dm-5” und “/dev/dm-6” bereitstellt. “/dev/dm-6” entspricht der Partition, die im virtuellen Gast als root-Filesystem gemountet wird.
Abschluss der Arbeiten mit Gast-Partitionen durch “kpartx -d”
Bitte nicht vergessen, nach dem Abschluss der Arbeiten mit den “virtuellen” Partitionen im KVM Host die Partitionen vor dem Neustart der virtuellen Maschinen wieder zu “umounten” und zur Sicherheit auch aus dem Device-Mapper zu entfernen. Letzteres ermöglicht “kpartx -d” – in unserem Beispiel:
kpartx -d /dev/volgrp1/vm_imap_hd0
Links
Natürlich ist die dargestellte Vorgehensweise nicht auf meinem Mist gewachsen. Deshalb stellvertretend für viele andere Links ein paar Hinweise auf Artikel, die für mich nützlich waren:
http://backdrift.org/mounting-a-file-system-on-a-partition-inside-of-an-lvm-volume
http://blog.normation.com/2011/04/07/mounting-partitions-stored-in-a-logical-volume-or-a-disk-image/
http://serverfault.com/questions/376421/how-to-access-partitions-inside-a-logical-volume-from-the-host-machine
Einige meiner Leser werden sich fragen, wie man die virtuellen Partitionen innerhalb eines logischen Volumes nun bei Bedarf in ihrer Größe abändern kann. Ein direktes Resizing mit LVM im Host ist hier natürlich nicht ohne größere Umwege möglich. Die Entwickler bei Red Hat haben aber den Befehl “virt-resize” bereitgestellt, der
im Zusammenspiel mit dem LVM-System des KVM-Hostes die erforderlichen Schritte sehr erleichtert. Hierzu seien dem interessierten Leser folgende Links ans Herz gelegt:
!!!!
http://unix-heaven.org/resizing-kvm-disk-image-lvm-the-easy-way
!!!!
http://www.pither.com/articles/2009/10/09/resize-ext3-in-lvm-in-partition-in-kvm-qemu-virtual-image-file
http://libguestfs.org/virt-resize.1.html
Viel Spass nun mit KVM, LVM, logischen Volumes und “virtuellen” Partitionen !