Public bug reported: This seems inexplicable but has been verified in a number of ways.
Given the following domain XML (from libvirt): <devices> <emulator>/usr/bin/kvm</emulator> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source dev='/dev/vg/instance-00000442_disk.rescue'/> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source dev='/dev/vg/instance-00000442_disk'/> <target dev='vdb' bus='virtio'/> <alias name='virtio-disk1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> creates the following qemu command line: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name instance-00000442 -S -M pc-1.0 -cpu core2duo,+lahf_lm,+rdtscp,+pdpe1gb,+avx,+osxsave,+xsave,+aes,+tsc- deadline,+popcnt,+x2apic,+sse4.2,+sse4.1,+dca,+pdcm,+xtpr,+cx16,+tm2,+est,+smx,+vmx,+ds_cpl,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds -enable-kvm -m 45056 -smp 16,sockets=16,cores=1,threads=1 -uuid 4080aa58-7e92-4d59-8fd4-38cc6cd6b1d1 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000442.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/vg /instance-00000442_disk.rescue,if=none,id=drive-virtio- disk0,format=raw,cache=none -device virtio-blk- pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio- disk0,bootindex=1 -drive file=/dev/vg/instance-00000442_disk,if=none,id =drive-virtio-disk1,format=raw,cache=none -device virtio-blk- pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=21,id=hostnet0 -device virtio-net- pci,netdev=hostnet0,id=net0,mac=fa:16:3e:4d:c1:78,bus=pci.0,addr=0x3 -netdev tap,fd=22,id=hostnet1 -device virtio-net- pci,netdev=hostnet1,id=net1,mac=fa:16:3e:55:26:4e,bus=pci.0,addr=0x4 -chardev file,id=charserial0,path=/var/lib/nova/instances/instance-00000442/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 10.145.0.11:0 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 The following bits are important: -drive file=/dev/vg/instance-00000442_disk.rescue,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/vg/instance-00000442_disk,if=none,id=drive-virtio-disk1,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 Given the following one would expect two devices inside the qemu guest (vda/vdb) with vda connected to /dev/vg/instance-00000442_disk.rescue and vdb connected to /dev/vg/instance-00000442_disk This is, however, NOT how they are connected. Both vda and vdb both connect to /dev/vg/instance-00000442_disk. This is verified in a number of ways: A) the actual contents of the drives, _disk was modified (touch /root/blah) and these changes did show on vda. B) disk I/O throughput. dd'ing large amounts of data to vda/vdb shows all data going to _disk, no writes/reads from _disk.rescue. C) strace'ing the process shows all writes/reads (pwrite /pread) for both vda and vdb going to the file descriptor associated with the _disk device. No writes/reads were observed that go to the file descriptor associated with the _disk.rescue device. qemu-1.0 and qemu-1.2 were both tested and appeared to have this issue. ** Affects: qemu Importance: Undecided Status: New -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1087035 Title: qemu plumbs virtual to wrong backing devices Status in QEMU: New Bug description: This seems inexplicable but has been verified in a number of ways. Given the following domain XML (from libvirt): <devices> <emulator>/usr/bin/kvm</emulator> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source dev='/dev/vg/instance-00000442_disk.rescue'/> <target dev='vda' bus='virtio'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source dev='/dev/vg/instance-00000442_disk'/> <target dev='vdb' bus='virtio'/> <alias name='virtio-disk1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> creates the following qemu command line: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name instance-00000442 -S -M pc-1.0 -cpu core2duo,+lahf_lm,+rdtscp,+pdpe1gb,+avx,+osxsave,+xsave,+aes ,+tsc- deadline,+popcnt,+x2apic,+sse4.2,+sse4.1,+dca,+pdcm,+xtpr,+cx16,+tm2,+est,+smx,+vmx,+ds_cpl,+dtes64,+pclmuldq,+pbe,+tm,+ht,+ss,+acpi,+ds -enable-kvm -m 45056 -smp 16,sockets=16,cores=1,threads=1 -uuid 4080aa58-7e92-4d59-8fd4-38cc6cd6b1d1 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-00000442.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -no-kvm-pit-reinjection -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/vg /instance-00000442_disk.rescue,if=none,id=drive-virtio- disk0,format=raw,cache=none -device virtio-blk- pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio- disk0,bootindex=1 -drive file=/dev/vg/instance- 00000442_disk,if=none,id=drive-virtio-disk1,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio- disk1,id=virtio-disk1 -netdev tap,fd=21,id=hostnet0 -device virtio- net- pci,netdev=hostnet0,id=net0,mac=fa:16:3e:4d:c1:78,bus=pci.0,addr=0x3 -netdev tap,fd=22,id=hostnet1 -device virtio-net- pci,netdev=hostnet1,id=net1,mac=fa:16:3e:55:26:4e,bus=pci.0,addr=0x4 -chardev file,id=charserial0,path=/var/lib/nova/instances/instance-00000442/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -device usb-tablet,id=input0 -vnc 10.145.0.11:0 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 The following bits are important: -drive file=/dev/vg/instance-00000442_disk.rescue,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/vg/instance-00000442_disk,if=none,id=drive-virtio-disk1,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 Given the following one would expect two devices inside the qemu guest (vda/vdb) with vda connected to /dev/vg/instance-00000442_disk.rescue and vdb connected to /dev/vg/instance-00000442_disk This is, however, NOT how they are connected. Both vda and vdb both connect to /dev/vg/instance-00000442_disk. This is verified in a number of ways: A) the actual contents of the drives, _disk was modified (touch /root/blah) and these changes did show on vda. B) disk I/O throughput. dd'ing large amounts of data to vda/vdb shows all data going to _disk, no writes/reads from _disk.rescue. C) strace'ing the process shows all writes/reads (pwrite /pread) for both vda and vdb going to the file descriptor associated with the _disk device. No writes/reads were observed that go to the file descriptor associated with the _disk.rescue device. qemu-1.0 and qemu-1.2 were both tested and appeared to have this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1087035/+subscriptions