Accessing the contents of a KVM disk image

Accessing the contents of a KVM disk image
Sat, 24 Nov 2007

A kernel based virtual machine (KVM) can use either an entire partition to simulate a disk for the guest operating system, or a single file. By default the file type used is a "raw" file compatible with other virtualization systems, like Xen. Other optional file types are more flexible, allowing compression and encryption of the contents (qcow2), or compatibility with VMware (vmdk). Access to the simulated file sytems contained within the file from outside the guest operating system is possible. For example, access from the host or real Linux system.

First a small warning, it is generally not advisable to modify/access the guest file systems while the guest virtual machine is running.
Map a loop device to the image file

In Linux and other Unix-like systems a file can be setup so that it can be treated like a device (such as a disk device). For example, this techniques allows mounting CD or DVD ISO image files, so that they appear just like a normal disk drive. This same technique can be used with raw VM image files.

The command losetup is used to associate files with loop devices. First check what the next available loopback device is (there may already be some used on the system). The -f argument is used to find the next available device:
#losetup -f /dev/loop0

In this case there are no other loop devices and /dev/loop0 is available. This can then be associated with our VM image file (in my case debianvm.img, an image containing a Debian operating system):
#losetup /dev/loop0 /var/vms/debianvm.img

Now device /dev/loop0 is mapped to the VM image file.
Accessing the partitions

Within a single image file there may be multiple (simulated) partitions (e.g. a system like Debian will usually have at least two, a main partition for the operating system and user files, and a swap partition). The partition table can be read from the new (loop) device and individual devices for each partition created (in a similar manner to a "real" disk device). This is done with the kpartx command (it creates map devices from device partition tables):
#kpartx -av /dev/loop0
 add map loop0p1 : 0 7727202 linear /dev/loop0 63
 add map loop0p5 : 0 449757 linear /dev/loop0 7727328

The -av arguments "add" partition mappings and reports on the result ("verbose" mode). Indeed the Debian image has two partitions. Devices for both of these were created in the /dev/mapper directory:
#ls -alF /dev/mapper
 brw-rw---- 1 root disk 253, 4 2007-11-24 14:56 loop0p1
 brw-rw---- 1 root disk 253, 5 2007-11-24 14:56 loop0p5

There are two new device files in /dev/mapper mapped to each partition within the VM disk image. These can be used just like normal partition device files:
#mount /dev/mapper/loop0p1 /mnt/debianvm
#ls /mnt/debianvm
 bin cdrom etc initrd lib media opt root srv tmp var
 boot dev home initrd.img lost+found mnt proc sbin sys usr vmlinuz
Undoing the process

As stated at the top of these notes, it is generally not a good idea to do this when the virtual machine is running. It is important to reverse this process and unmout/unmap the partitions and image file:
#unmount /mnt/debianvm
#kpartx -dv /dev/loop0
 del devmap : loop0p1
 del devmap : loop0p5
#losetup -d /dev/loop0

Note, there is an extra complication when accessing LVM partitions (e.g. used by default in Fedora file systems). I will add a note on this soon.