Direkter Zugriff auf qemu-Images von einem Virtualisierungs-Host

Aus Linupedia.org
Wechseln zu: Navigation, Suche

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.


Unterstützte Dateiformate

Diese Formate werden unterstützt:

  • raw
  • host_device
  • qcow2
  • qcow
  • cow
  • vdi
  • vmdk
  • vpc
  • cloop

Details: Supported image file formats Englisch.png

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

Links