[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] dynamic scsi disk attach seems to be broken in qemu(-kvm)-0.11, libvirt-0.7.1



We're experiencing what we believe to be a regression in qemu-kvm-0.11
and libvirt-0.7.0, from previous versions of kvm-84 and libvirt-0.6.1:
Dynamically attaching sdb (a second scsi disk) fails.  (Note that I
have tested this against libvirt-0.7.1 built from source as well--same
results.)

Here are some instructions to reproduce this issue:

Create some small auxiliary storage to dynamically add to a running VM.
  (host) $ dd if=/dev/zero of=/tmp/foo bs=1M count=64

Boot a vm in under qemu-kvm-0.11.0 like this:
  (host) $ kvm -drive file=server.img,if=scsi,boot=on -boot c

To reproduce the problem, you must use if=scsi. This problem manifests
itself when subsequent scsi storage devices are added. If the device
is the first scsi device on the system, then it would succeed. It's
the 2nd scsi device that causes the problem.

Once the system is booted, login and in the vm, load this module:
  (vm) $ sudo modprobe acpiphp

Check that the acpiphp slots are loaded in dmesg. And note that there
is only one /dev/sd[a-z] device.

Now, drop to the qemu console with ctrl-alt-2, and add the storage:
  (qemu) pci_add auto storage file=/tmp/foo,if=scsi
  OK domain 0, bus 0, slot 6, function 0

Switch back to the vm linux shell with ctrl-alt-1, and look at the dmesg output.
  (vm) $ dmesg | tail -n 12
[ 44.033397] pci 0000:00:06.0: reg 10 io port: [0x00-0xff]
[ 44.033443] pci 0000:00:06.0: reg 14 32bit mmio: [0x000000-0x0003ff]
[ 44.033486] pci 0000:00:06.0: reg 18 32bit mmio: [0x000000-0x001fff]
[ 44.033899] pci 0000:00:02.0: BAR 6: bogus alignment [0x0-0x0] flags 0x2
[ 44.033975] decode_hpp: Could not get hotplug parameters. Use defaults
[ 44.042277] sym53c8xx 0000:00:06.0: enabling device (0000 -> 0003)
[ 44.043230] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
[ 44.043247] sym53c8xx 0000:00:06.0: PCI INT A -> Link[LNKB] -> GSI 11
(level, high) -> IRQ 11
[ 44.045237] sym1: <895a> rev 0x0 at pci 0000:00:06.0 irq 11
[ 44.047586] sym1: No NVRAM, ID 7, Fast-40, LVD, parity checking
[ 44.055399] sym1: SCSI BUS has been reset.
[ 44.063329] scsi3 : sym-2.2.3

More importantly, note that no /dev/sd[b-z] device shows up.

If you now drop to the qemu console with ctrl-alt-2, and do this:
  (qemu) pci_add auto storage file=/tmp/foo,if=virtio
  OK domain 0, bus 0, slot 7, function 0

Going back to the vm with ctrl-alt-1, you can now see a new /dev/vda
device registered.

Now, all of that said, it is actually possible to hot-add a second
scsi device. However, as far as I can tell, this method is not yet
supported by libvirt.  It looks to me that with modern qemu, you have
to do it this way:

Drop to a qemu console with ctrl-alt-2. Get the address of the current scsi bus:
  (qemu) info pci
  Look for "SCSI Controller". In my case, it's on Bus 0, device 4, function 0

Now instead of pci_add, use drive_add
  (qemu) drive_add 0:4 file=/tmp/foo,if=scsi
  OK bus 0, unit 1

This is not ideal, however, as I tried re-scan the scsi bus with
rescan-scsi-bus.sh (from scsitools) without luck. It did not pick up
the new sdb device. However, I did reboot the vm, and voila, I now
have /dev/sdb.

I would like some advice on how to proceed with this bug, and where
the solution lies...in qemu or in libvirt.  Ultimately, I would like
the behavior we had in our previous release with kvm-84 and
libvirt-0.6.1, where we could dynamically add scsi devices without a
problem, using:
  pci_add 1 storage file=/tmp/foo,if=scsi

Can anyone else reproduce this?  Is this considered a regression by
anyone else?  Where should I look to solve this, in libvirt, or in
qemu?

-- 
:-Dustin


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]