Comment 13 for bug 1221190

I don't see this behavior either, although I see different things from Daniel.

I don't see the contents of the evil backing file in /dev/vdb from inside the rescuing guest, but I do see the path I set as the first string, which means the dd worked:

$ sudo strings /dev/vdb | head -1
/etc/libvirt/libvirt.conf

My libvirt config does show qcow2 as the disk format though:

<disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='none'/>
      <source file='/opt/stack/data/nova/instances/77304a99-9453-4e21-8d5b-ccf61dfa5c23/disk'/>
      <target dev='vdb' bus='virtio'/>
      <alias name='virtio-disk1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</disk>

However, if I look at the image itself:

# qemu-img info /opt/stack/data/nova/instances/77304a99-9453-4e21-8dbb-ccf61dfa5c23/disk
image: /opt/stack/data/nova/instances/77304a99-9453-4e21-8d5b-ccf61dfa5c23/disk
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 12M
cluster_size: 65536
backing file: /opt/stack/data/nova/instances/_base/c193393ae54e6028da799b4afdd8ccd8db6)

and if I follow the backing file reference:

# qemu-img info /opt/stack/data/nova/instances/_base/c193393ae54e6028da799b4afdd8ccd8db6efc07
image: /opt/stack/data/nova/instances/_base/c193393ae54e6028da799b4afdd8ccd8db6efc07
file format: raw
virtual size: 24M (25165824 bytes)
disk size: 24M

it backs up to a raw file. This was on a precise machine:

ii libvirt-bin 0.9.8-2ubuntu17 programs for the libvirt library

On a very recent commit from master:

commit 78810135d851a4db60a2cb2e2fbdb11d032a8b97
Merge: 5429048 2d13161
Author: Jenkins <email address hidden>
Date: Wed Sep 25 19:56:34 2013 +0000