Mounting a partition from raw image is pretty simple:

    losetup /dev/loop0 image.img
    kpartx -a /dev/loop0
    mount /dev/mapper/loop0p1 /mnt/image

 

If kernel parameter (as loop in compiled into Fedora’s kernel) like loop.max_part=63 added it is even simplier:

    losetup /dev/loop0 image.img
    mount /dev/loop0p1 /mnt/image

 

Alternative way is to specify direct offset to partition:

    mount image.img /mnt/image -o loop,offset=32256

 

To mount qcow2 images there is (at least in F-11 qemu) very useful qemu-nbd util. It shares image through kernel network block device protocol and this allows to mount it:

    modprobe nbd max_part=63
    qemu-nbd -c /dev/nbd0 image.img
    mount /dev/nbd0p1 /mnt/image

 

If LVM is present on image it could be initialized with:

    vgscan
    vgchange -ay
    mount /dev/VolGroupName/LogVolName /mnt/image

 

Finishing is done with (depending on how it was initalized):

    umount /mnt/image
    vgchange -an VolGroupName
    killall qemu-nbd
    kpartx -d /dev/loop0
    losetup -d /dev/loop0

 

qcow2 images are not flat files, see qemu-img(1). KVM ships with qemu-nbd,
which lets you use the NBD protocol to share the disk image on the network.

 

First, for partition nbd partition support you need to be running kernel
2.6.26 (commit, changelog) or greater. For ubuntu users, that means it’s time
to upgrade to intrepid ibex. Load the nbd module with:

 

sudo modprobe nbd max_part=8

 

If you leave off the max_part attribute, partitions are not supported and
you’ll be able to access the disk, but not have device nodes for any of the
partitions. Running

 

sudo qemu-nbd root.qcow2

 

will bind to all interfaces (0.0.0.0) and share the disk on the default port
(1024). It’s important to note that the nbd kernel module produces /dev/nbd0
while the nbd-client man page recommends /dev/nb0 in it’s examples. The error
message isn’t so clear, see lp:290076.

 

# nbd-client localhost 1024 /dev/nb0
Error: Can not open NBD: No such file or directory

 

This can all be reduced in steps using the ‘–connect’ option of qemu-nbd, like
this:

 

sudo qemu-nbd --connect=/dev/nbd0 root.qcow2

At which point you can view the disk partitions:

sudo fdisk /dev/nbd0

or mount a disk, such as

mount /dev/nbd0p1 /mnt

qemu-img convert -f qcow hda.qcow -O raw had.raw

losetup /dev/loop1 hda.raw

 

fdisk -l /dev/loop1

 

Disk /dev/loop1: 4194 MB, 4194816000 bytes
128 heads, 63 sectors/track, 1015 cylinders, total 8193000 sectors
Units = sectors of 1 * 512 = 512 bytes

      Device Boot      Start         End      Blocks   Id  System
/dev/loop1p1   *          63     8176895     4088416+   7  HPFS/NTFS

 

losetup -d /dev/loop1

32256 = 63 * 512

 

losetup -o 32256 /dev/loop1 hda.raw

 sfdisk -l /dev/loop0
Disk /dev/loop0: cannot get geometry

Disk /dev/loop0: 1305 cylinders, 255 heads, 63 sectors/track
Warning: The partition table looks like it was made
  for C/H/S=*/128/63 (instead of 1305/255/63).
For this listing I'll assume that geometry.
Units = cylinders of 4128768 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/loop0p1   *      0+    518     519-   2092576+   7  HPFS/NTFS
/dev/loop0p2          0       -       0          0    0  Empty
/dev/loop0p3          0       -       0          0    0  Empty
/dev/loop0p4          0       -       0          0    0  Empty

 

Mounting KVM qcow2 qemu disk images
Published by btmon Mon, 27 Oct 2008 17:24:13 -0700in Uncategorized.
qcow2 images are not flat files, see qemu-img(1). KVM ships with qemu-nbd,
which lets you use the NBD protocol to share the disk image on the network.

 

First, for partition nbd partition support you need to be running kernel
2.6.26 (commit, changelog) or greater. For ubuntu users, that means it’s time
to upgrade to intrepid ibex. Load the nbd module with:

 

sudo modprobe nbd max_part=8

 

If you leave off the max_part attribute, partitions are not supported and
you’ll be able to access the disk, but not have device nodes for any of the
partitions. Running

 

sudo qemu-nbd root.qcow2

will bind to all interfaces (0.0.0.0) and share the disk on the default port
(1024). It’s important to note that the nbd kernel module produces /dev/nbd0
while the nbd-client man page recommends /dev/nb0 in it’s examples. The error
message isn’t so clear, see lp:290076.

 

# nbd-client localhost 1024 /dev/nb0
Error: Can not open NBD: No such file or directory

 

This can all be reduced in steps using the ‘–connect’ option of qemu-nbd, like
this:

sudo qemu-nbd --connect=/dev/nbd0 root.qcow2

At which point you can view the disk partitions:

sudo fdisk /dev/nbd0

or mount a disk, such as

mount /dev/nbd0p1 /mnt

 

Network Block Devices
Network Block Devices (http://nbd.sourceforge.net) sind virtuelle Festplatten,
die von einem NBD-Server über TCP/IP bereitgestellt werden. Als Network Block
Devices (NBD) können Festplatten, Festplattenpartition, CDs/DVDs, Floppies
oder Image-Dateien auf dem NBD-Server dienen. Andere Rechner können sich über
eine TCP/IP-Verbindung mit dem NBD-Server verbinden und die Network Block
Devices wie eigene lokale Festplatten benutzen. Die Zugriffsgeschwindigkeit
ist, bedingt durch die Übertragungsrate im Netzwerk, nicht hoch. Ab Kernel
2.6.26 unterstützt Linux Network Block Devices. Das Kernel-Modul nbd legt dazu
die Devices /dev/nb* an. Unter Linux beinhalten die Pakete qemu und kvm die
speziellen NBD-Server qemu-nbd beziehungsweise kvm-nbd. Mit diesem Tools
können Network Block Devices zur Verfügung gestellt werden. Mit der Option -k
wird ein Unix-Socket verwendet. Die Option -t bewirkt, dass das Programm nicht
beim Abbruch der Verbindung beendet wird. Hier als Beispiel der Aufruf von
qemu-nbd. Bei kvm-nbd werden die gleichen Optionen angewendet.

Host ~$ qemu-nbd -t -k /var/lock/qemu-nbd Platte.img
Auf einer zweiten Konsole des Host-Systems kann ein Gast-System unter QEMU
oder KVM von diesem Network Block Device booten.

Host ~$ qemu -hda nbd:unix:/var/lock/qemu-nbd
Wird ein Network Block Device über TCP/IP exportiert, ist der Port anzugeben.
Wird der Default-Port 1024 verwendet, kann diese Angabe entfallen. Im
folgenden Beispiel wird die Image-Datei Platte.img per TCP/IP über das Port
1025 als Network Block Device zur Verfügung gestellt.

Host ~$ qemu-nbd -t -p 1025 Platte.img
Auf einer zweiten Konsole des Host-Systems kann eine Instanz von diesem Image
booten.

 

Host ~$ qemu -hda nbd:localhost:1025
Soll von einem anderen Rechner auf dieses Network Block Device zugegriffen
werden, so ist der Name oder die IP-Adresse des NBD-Servers anzugeben.

 

Host2 ~$ qemu -hda nbd:my_nbd_server:1025
Die Option --shared=num ermöglicht, dass mehrere Gast-Systeme auf ein Network
Block Device zugreifen können. Die maximale Anzahl definiert der Wert num
(Default = 1).

 

Host1 ~$ qemu-nbd -t -p 1025 --share=2 Platte.img
Auf einem anderen Rechner kann eine Instanz mit diesem Network Block Device
gestartet werden.

 

Host2 ~$ qemu -hda nbd:my_nbd_server:1025
Auf einem weiteren Rechner kann eine zweite Instanz gestartet werden.

 

Host3 ~$ qemu -hda nbd:my_nbd_server:1025
Mit der Option -s oder --snapshot werden die Änderungen nicht auf das Image,
sondern in temporäre Dateien geschrieben. Für das Gast-System ist scheinbar
das Image beschreibbar. Diese Änderungen gehen beim Herunterfahren der Instanz
verloren. Diese Option verlangsamt den Zugriff.

 

Host ~$ qemu-nbd -s -t -p 1025 Platte.img
Ein kompletter Schreibschutz aktiviert die Option -r (--read-only). Viele
Betriebssysteme können nicht von einem schreibgeschützten Medium booten.
Deshalb ist diese Option eher für Live-CDs oder zusätzliche Speichermedien
interessant. Im folgenden Beispiel werden zwei Network Block Devices
gleichzeitig auf unterschiedlichen Ports zur Verfügung gestellt. Das Image
Daten.img ist schreibgeschützt.

 

Host1 ~$ qemu-nbd -s -t -p 1025 Platte
Host1 ~$ qemu-nbd -r -t -p 1026 Daten.img
Beide Network Block Devices können von einer Instanz eingebunden werden.

 

Host2 ~$ qemu -hda nbd:my_nbd_server:1025 \
         -hdb nbd:my_nbd_server:1026
Neben Images können auch CDs, DVDs und Floppies als Network Block Device
exportiert werden. So können unterschiedliche Installationsmedien auf einen
zentralen Server bereitgestellt werden.

Host1 ~$ qemu-nbd -t -p 1025 /dev/cdrom
Dieses Network Block Device wird von einer Instanz auf einen anderen Rechner
eingebunden.

 

Host2 ~$ qemu -cdrom nbd:my_nbd_server:1025
Mit der Option --connect=DEV kann das Image direkt einem konkreten Network
Block Device zugewiesen werden. Der Parameter DEV kennzeichnet das Device.

Host ~$ qemu-nbd --connect=/dev/nbd0 Platte.img
Es ist möglich dieses Device zu partitionieren oder zu mounten.

Host ~$ sudo fdisk -l /dev/nbd0
Host ~$ sudo mount /dev/nbd0p1 /mnt
Alle Optionen von qemu-nbd zeigt die Option --help an.

 

Host1 ~$ qemu-nbd –help
Usage: qemu-nbd [OPTIONS] FILE
QEMU Disk Network Block Device Server
 -p, --port=PORT      port to listen on (default '1024')
 -o, --offset=OFFSET  offset into the image
 -b, --bind=IFACE     interface to bind to (default '0.0.0.0')
 -k, --socket=PATH    path to the unix socket
                      (default '/var/lock/qemu-nbd-DEVICE')
 -r, --read-only      export read-only
 -P, --partition=NUM  only expose partition NUM
 -s, --snapshot       use snapshot file
 -n, --nocache        disable host cache
 -c, --connect=DEV    connect FILE to the local NBD device DEV
 -d, --disconnect     disconnect the specified device
 -e, --shared=NUM     device can be shared by NUM clients
 -t, --persistent     don't exit on the last connection
 -v, --verbose        display extra debugging information
 -h, --help           display this help and exit
 -V, --version        output version information and exit
Als schnellere Alternative zu qemu-nbd kann unter Linux das Paket nbd-server
oder für den Cluster-Einsatz das Paket gnbd-server verwendet werden.
nbd-server bietet einen besseren Zugriffsschutz als qemu-nbd.

 

Host ~$ sudo apt-get install nbd-server
Um ein Image als Network Block Device zur Verfügung zu stellen, ist der Port
und das Image mit dessen Pfad anzugeben. Empfehlenswert ist, mit der Option -a
ein Timeout in Sekunden anzugeben. Damit verhindert man, dass unnötige
Prozesse bei längerer Inaktivität im Speicher verbleiben.

 

Host1 ~$ nbd-server 1025 /Pfad/Platte.img -a 100
Von einem zweiten Rechner kann ein Gast-System unter QEMU oder unter der
Kernel-based Virtual Machine von diesem Network Block Device gestartet werden.

 

Host2 ~$ qemu -hda nbd:my_nbd_server:1025
Nach Beenden der Instanz ist zu kontrollieren, ob noch der Prozess des
NBD-Server aktiv ist.

 

Host1 ~$ ps aux | grep nbd-server
Nicht mehr benötigte Prozesse sind zu beenden.

 

Host1 ~$ killall nbd-server
Ein kompletter Schreibschutz für das Image aktiviert die Option -r.

 

Host ~$ nbd-server 1025 /Pfad/Platte.img -r -a 100
Mit der Option -c (Copy on write) werden die Änderungen nicht auf das Image
geschrieben, sondern in temporäre Dateien (*.diff). Für das Gast-System ist
scheinbar das Image beschreibbar. Diese Änderungen gehen beim Herunterfahren
der Instanz verloren. Diese Option verlangsamt den Zugriff.

 

Host ~$ nbd-server 1025 /Pfad/Platte.img -c -a 100
Alle Optionen zeigt die Man-Page an.

 

Host ~$ man nbd-server
Für den Zugriff auf Network Block Devices kann unter Linux das Paket
nbd-client beziehungsweise gnbd-client verwendet werden. Diese NBD-Clients
unterstützen nicht das Booten von einem Network Block Device. Die Installation
des Paketes nbd-client erfolgt unter Ubuntu mit einer Befehlszeile.

 

Host ~$ sudo apt-get install nbd-client
Wurde ein Network Block Device mit qemu-nbd oder nbd-server zur Verfügung
gestellt, kann mit dem nbd-client darauf zugegriffen werden. Dazu ist die
IP-Adresse oder der Host-Name des Servers, das Port und das lokale Device
anzugeben.

 

Host ~$ sudo nbd-client my_nbd_server 1025 /dev/nbd0
Ein installiertes Gast-System kann mit QEMU/KVM gestartet werden.

 

Host ~$ sudo chmod 777 /dev/nbd0

Host ~$ qemu -hda /dev/nbd0
Alle Optionen zeigt die Man-Page an.

 

Host ~$ man nbd-client
[bearbeiten] Links

# CPU affinity

Tip: Running your VM on specific CPUs
Monday, June 2, 2008 - 04:15 Haydn Solomon
One of the benefits of the qemu/kvm model is management of the qemu process using linux userspace utilities as qemu runs in userspace as a normal linux process. One of these useful linux utilities is called taskset which allows setting the cpu affinity of a process. This is just a fancy way of saying bonding a process to a specific set of cpu(s). Why would you want to do this? The short answer is Load balancing. With multicore cpus becoming the de facto standard, there are some very practical uses of this when it comes to virtualization. On a typical multicore cpu today, each core has enough power to easily run a physical machine so you can see the practical application of this; pin a virtual machine to a cpu core. This is applicable for most applications. If your application needs more cpu cycles you can scale up by pinning your virtual machine to multiple cores. Using the linux taskset utility you have two options in applying it to your virtual machine process. You can set the cpu affinity of an already running process or you can start the process using a specific cpu affinity. The fact that you can specify the cpu affinity of an already running process really adds to the flexibility and usefulness of this utility. Let’s look at both options for manipulating your kvm virtual machines processes.

 

Start a VM with specific CPU affinity
To start your qemu/kvm virtual machine on logical cpus 0 and 1, start your virtual machine with the following command.

taskset 0x00000003 qemu-system-x86_64 –hda windows.img –m 512When starting a new process using taskset, you have to specify one argument which represents a bitmask of the cpus you want to bond the process to. As you can see this mask argument is in hexadecimal. The mask value 0x00000003 represents logical cpu numbers 0 and 1 as it starts counting from 0. To verify that your VM is running on logical cpus 0 and 1, use the taskset to verify this using the process id of your virtual machine. To get the process id of your virtual machine process use the

following command.

[root@localhost ~]# ps -eo pid,comm | grep qemu
 7532 qemu-system-x86
From the above command the process id of the qemu/kvm process is 7532. Run the following command to verify the cpu affinity of the virtual machine process.

 

[root@localhost ~]# taskset -p 7532
pid 7532's current affinity mask: 3
This is saying that the bitmask representing the cpu affinity of the process is 3. This bitmask is more machine friendly. To get a more human friendly verification run the following command instead.

 

[root@localhost ~]# taskset -c -p 7532
pid 7532's current affinity list: 0,1
This is much more human friendly and verifies that your virtual machine is running on logical cpus 0 and 1.

 

Modify an already running VM process
As mentioned earlier, taskset also allows you to modify your already running virtual machine process so that you can change the cpu affinity. Let’s change it so that it only runs on logical cpu 0. Using the same process id in the section above, run the following command.

 

[root@localhost ~]# taskset -p 0x00000001 7532
pid 7532's current affinity mask: 3
pid 7532's new affinity mask: 1
Taskset sets the affinity and shows the old and new bitmask but you want to also verify using the human friendly way with the following command.

 

[root@localhost ~]# taskset -c -p 7532
pid 7532's current affinity list: 0
You can see that your virtual machine process is running on logical cpu 0 only.

 

Summary
As multicore technology continue to increase the number of cores, the application of bonding virtual machine processes to specific cpus will become more commonplace. This is one clear example of how the qemu/kvm model leverages linux to its advantage. There was absolutely no development needed by KVM maintainers in order for users to have access to this practical facility

pstree -p -u kvm  |sed -e 's/+/\n/g' |sed -e 's/[^0-9]//g' |grep -v ^$ | while read pid ; do taskset -p e $pid ; done