Direkter Zugriff auf qemu-Images von einem Virtualisierungs-Host
 |
Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist. |
--Gehrke (Diskussion) 22:30, 13. Jan. 2014 (CET)
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
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
