Direkter Zugriff auf qemu-Images von einem Virtualisierungs-Host
Manche Virtualisierungsplattformen wie beispielsweise KVM, Xen oder VirtualBox verwenden Container-Formate aus dem qemu-Projekt zur Emulierung von Festplatten für virtuelle Maschinen. Dieser Artikel zeigt auf, wie man direkt auf das Disk-Image einer virtuellen Maschine zugreift, um es beispielsweise in das lokale Dateisystem des Host-Systems einzuhängen.
Dies kann beispielsweise dann sehr nützlich sein, wenn die virtuelle Maschine aus irgendwelchen Gründen nicht mehr startbar ist.
| Achtung: |
|
Um Schäden am Dateisystem zu vermeiden, sollte das Image niemals gleichzeitig an mehreren Stellen schreibend verwendet werden. Während es auf dem Host-System gemountet ist, sollte die virtuelle Maschine nicht gestartet sein bzw. werden. |
Inhaltsverzeichnis
Unterstützte Dateiformate
Diese Formate werden unterstützt:
- raw
- host_device
- qcow2
- qcow
- cow
- vdi
- vmdk
- vpc
- cloop
Details: Supported image file formats 
Mounten eines qemu-Images in den Virtualisierungs-Host
Manchmal besteht die Notwendigkeit, innerhalb des Virtualisierungs-Hosts direkt auf die Dateisysteme einer virtuellen Maschine zuzugreifen. Bei Datenträgern, die beispielsweise im VDI-Format (dem aktuellen Standard von VirtualBox) vorliegen, kann das wie folgt über das Network Block Device protocol mittels 'qemu-nbd' durchgeführt werden, welches sich im Package 'qemu-tools' befindet.
Das folgende Beispiel soll das Verfahren verdeutlichen. Die Partitionierung der virtuellen Maschine beinhaltet 3 primäre Partitionen und wird im nachstehenden Diagramm dargestellt:
user@linux-xc89:~> lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 8G 0 disk ├─sda1 8:1 0 101M 0 part /boot ├─sda2 8:2 0 6,6G 0 part │ ├─system-root 253:0 0 6,1G 0 lvm / │ └─system-swap 253:1 0 512M 0 lvm [SWAP] └─sda3 8:3 0 1,3G 0 part /images-pp
Hinweis: Hier handelt es sich um eine Konfiguration für einen ganz bestimmten Zweck und soll keinesfalls als beispielhaft für eine sinnvolle Partitionierung im produktiven Einsatz gelten!
NBD-Ressourcen erzeugen und verbinden
Zuerst wird das Modul geladen:
# modprobe nbd max_part=16
Diese Aktion wird in den Logs verzeichnet:
2014-01-13T21:10:09.044207+01:00 j2 kernel: [ 2724.312673] nbd: registered device at major 43
Als nächstes wird das Image mit dem virtuellen Device 'nbd0' verbunden:
# qemu-nbd -c /dev/nbd0 test1.vdi
Log-Eintrag:
2014-01-13T21:28:49.381445+01:00 j2 kernel: [ 3844.650818] nbd0: p1 p2 p3
Dieses Image ist in drei primäre Partitionen unterteilt, für welches jeweils ein virtuelles Sub-Device zur Verfügung gestellt wird:
# ls /dev/nbd0* /dev/nbd0 /dev/nbd0p1 /dev/nbd0p2 /dev/nbd0p3
NBD-Device mounten
Unter Verwendung dieses Sub-Devices kann nun das jeweilige Ziel (in diesem Beispiel die erste primäre Partion) gemountet werden:
# mount /dev/nbd0p1 /mnt
Im Log-Eintrag erkennt man, dass ein ext4-Dateisystem automatisch erkannt und eingebunden wurde:
2014-01-13T21:37:21.090207+01:00 j2 kernel: [ 4356.359738] EXT4-fs (nbd0p1): mounted filesystem with ordered data mode. Opts: (null)
Anschließend stehen die Dateien dieses Images mit Schreibberechtigung eingehängt unter /mnt zur Verfügung:
# echo "42" > /mnt/test.txt # cat /mnt/test.txt 42
NBD-Ressourcen freigeben
Nach Verwendung sollten die Ressourcen in umgekehrter Reihenfolge wieder geschlossen und freigegeben werden:
# umount /dev/nbd0p1 # qemu-nbd -d /dev/nbd0 /dev/nbd0 disconnected
Log-Eintrag:
2014-01-13T21:43:36.854200+01:00 j2 kernel: [ 4732.123845] block nbd0: NBD_DISCONNECT 2014-01-13T21:43:36.854218+01:00 j2 kernel: [ 4732.123956] block nbd0: Unexpected reply (ffff88005bbcdca8) 2014-01-13T21:43:36.854219+01:00 j2 kernel: [ 4732.123976] block nbd0: queue cleared
Zuletzt wird das Modul entladen:
# rmmod nbd
Log-Eintrag:
2014-01-13T21:51:04.833896+01:00 j2 kernel: [ 5180.101376] nbd: unregistered device at major 43
