[Qemu-devel] [Bug 1087035] [NEW] qemu plumbs virtual to wrong backing devices

[Adam Jacob Muller]

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