Bug#773286: Info received (It looks like a conspiracy between libvirt and kvm)
Well, I've upgraded to: # dpkg -l libvirt* qemu* | grep '^ii' ii libvirt-bin 1.2.9-6~bpo70+1amd64 programs for the libvirt library ii libvirt-clients 1.2.9-6~bpo70+1amd64 programs for the libvirt library ii libvirt-daemon 1.2.9-6~bpo70+1amd64 programs for the libvirt library ii libvirt-daemon-system 1.2.9-6~bpo70+1 amd64Libvirt daemon configuration files ii libvirt0 1.2.9-6~bpo70+1amd64library for interfacing with different virtualization systems ii qemu-kvm 2.1+dfsg-9~bpo70+1 amd64QEMU Full virtualization on x86 hardware ii qemu-system-common 2.1+dfsg-9~bpo70+1 amd64QEMU full system emulation binaries (common files) ii qemu-system-x86 2.1+dfsg-9~bpo70+1 amd64 QEMU full system emulation binaries (x86) ii qemu-utils 2.1+dfsg-9~bpo70+1 amd64QEMU utilities But I get the same results: adriatic:~# virsh attach-device cedric.CalvaEDI.COM zz.xml error: Failed to attach device from zz.xml error: internal error: unable to execute QEMU command 'device_add': Bus 'pci.0' does not support hotplugging However, I have found a clue: cedric:~# dmesg | grep -i ACPI [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI BIOS Error (bug): A valid RSDP was not found (20140424/tbxfroot-211) [0.245347] ACPI: Interpreter disabled. [0.351414] pnp: PnP ACPI: disabled And, looking on the host syststem I see: adriatic:~# ps -ef | grep qemu | grep --color=always acpi 107 3088 1 1 12:38 ?00:01:27 qemu-system-x86_64 -enable-kvm -name cedric.CalvaEDI.COM -S -machine pc-1.1,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 99cfca83-cf28-ce9b-86a4-947debc202b5 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/cedric.CalvaEDI.COM.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -no-acpi -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/disk/by-id/md-name-cedric:root,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/disk/by-id/md-name-belgic:archive,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:65:2d:8e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on Note: ... -no-acpi ... No ACPI, no hotplug? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286:
19.12.2014 16:50, John Hughes wrote: Note: ... -no-acpi ... No ACPI, no hotplug? The linux guest-side module to handle hotplug is acpiphp. I think the name speaks for itself. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286:
19.12.2014 16:59, Michael Tokarev wrote: 19.12.2014 16:50, John Hughes wrote: Note: ... -no-acpi ... No ACPI, no hotplug? The linux guest-side module to handle hotplug is acpiphp. I think the name speaks for itself. Also, libvirt isn't right (IMHO) to stick with particular machine version (in your case, -M pc-1.1). It is needed for certain guest OS types, for example windows, to keep its activation changes (so that hw should not change). Linux is much more tolerant for hw changes. And even for windows it does not help in all cases (provided you don't use corporate version of this OS where hw changes are not relevant). Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286:
On 19/12/14 14:59, Michael Tokarev wrote: 19.12.2014 16:50, John Hughes wrote: Note: ... -no-acpi ... No ACPI, no hotplug? The linux guest-side module to handle hotplug is acpiphp. I think the name speaks for itself. When I can get my users to stop doing real work to let me play with my toy I'll try with featureacpi//feature. If it works then I contend the bug is the error message -- it would be really helpful if it said You can't hotplug because you haven't got ACPI. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286:
19.12.2014 17:42, John Hughes wrote: [] If it works then I contend the bug is the error message -- it would be really helpful if it said You can't hotplug because you haven't got ACPI. acpi is not the only possible way. More recent qemu (not pc-1.1 which you used) also has pcie bus, which does support hotplugging without acpi. But you used both pc-1.1 (old non-pcie machine) and no-acpi. Also, I _think_ hotplug can be disabled by a command-line switch (not sure but think). All ways leads to bus-enable_hotplug property set to false, which is being checked right before printing that error message. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286:
On 19/12/14 15:10, Michael Tokarev wrote: Also, libvirt isn't right (IMHO) to stick with particular machine version (in your case, -M pc-1.1). It is needed for certain guest OS types, for example windows, to keep its activation changes (so that hw should not change). Linux is much more tolerant for hw changes. And even for windows it does not help in all cases (provided you don't use corporate version of this OS where hw changes are not relevant). That's libvirt's translation of my previous Xen configuration. (In fact I think that all of my problems have come about because of libvirt being rather dumb about converting from Xen to KVM). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286:
On 19/12/14 15:53, Michael Tokarev wrote: acpi is not the only possible way. More recent qemu (not pc-1.1 which you used) also has pcie bus, which does support hotplugging without acpi. But you used both pc-1.1 (old non-pcie machine) and no-acpi. Ok, thanks. Still waiting for people to stop work so I can try this. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286: Happiness!
Ok, I've added featureacpi//feature and got rid of the pc-1.1 rubbish, now the qemu looks like: qemu-system-x86_64 -enable-kvm -name cedric.CalvaEDI.COM -S -machine pc-i440fx-2.1,accel=kvm,usb=off -m 8192 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 99cfca83-cf28-ce9b-86a4-947debc202b5 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/cedric.CalvaEDI.COM.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/disk/by-id/md-name-cedric:root,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/disk/by-id/md-name-belgic:archive,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=25 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:65:2d:8e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 -msg timestamp=on and when I try the virsh attach-device I get: adriatic:~# virsh attach-device cedric.CalvaEDI.COM zz.xml Device attached successfully On the guest I see that /dev/vdc has been created. I get an amazing amount of rubbish in the guest dmesg: [ 872.777513] pci :00:02.0: [1af4:1001] type 00 class 0x01 [ 872.778795] pci :00:02.0: reg 0x10: [io 0x-0x003f] [ 872.778862] pci :00:02.0: reg 0x14: [mem 0x-0x0fff] [ 872.781190] pci :00:02.0: BAR 1: assigned [mem 0xc000-0xcfff] [ 872.781238] pci :00:02.0: BAR 0: assigned [io 0x1000-0x103f] [ 872.781272] pci :00:00.0: no hotplug settings from platform [ 872.781275] pci :00:00.0: using default PCI settings [ 872.781326] pci :00:01.0: no hotplug settings from platform [ 872.781328] pci :00:01.0: using default PCI settings [ 872.781378] ata_piix :00:01.1: no hotplug settings from platform [ 872.781380] ata_piix :00:01.1: using default PCI settings [ 872.781429] uhci_hcd :00:01.2: no hotplug settings from platform [ 872.781432] uhci_hcd :00:01.2: using default PCI settings [ 872.781533] piix4_smbus :00:01.3: no hotplug settings from platform [ 872.781537] piix4_smbus :00:01.3: using default PCI settings [ 872.781606] virtio-pci :00:03.0: no hotplug settings from platform [ 872.781610] virtio-pci :00:03.0: using default PCI settings [ 872.781677] virtio-pci :00:04.0: no hotplug settings from platform [ 872.781680] virtio-pci :00:04.0: using default PCI settings [ 872.781746] virtio-pci :00:05.0: no hotplug settings from platform [ 872.781749] virtio-pci :00:05.0: using default PCI settings [ 872.781815] virtio-pci :00:07.0: no hotplug settings from platform [ 872.781818] virtio-pci :00:07.0: using default PCI settings [ 872.781885] pci :00:02.0: no hotplug settings from platform [ 872.781888] pci :00:02.0: using default PCI settings [ 872.782255] virtio-pci :00:02.0: enabling device ( - 0003) [ 872.833568] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11 [ 872.836572] virtio-pci :00:02.0: irq 47 for MSI/MSI-X [ 872.836609] virtio-pci :00:02.0: irq 48 for MSI/MSI-X [ 872.840793] vdc: unknown partition table [ 872.841169] pci :00:00.0: no hotplug settings from platform [ 872.841172] pci :00:00.0: using default PCI settings [ 872.841225] pci :00:01.0: no hotplug settings from platform [ 872.841228] pci :00:01.0: using default PCI settings [ 872.841278] ata_piix :00:01.1: no hotplug settings from platform [ 872.841280] ata_piix :00:01.1: using default PCI settings [ 872.841330] uhci_hcd :00:01.2: no hotplug settings from platform [ 872.841332] uhci_hcd :00:01.2: using default PCI settings [ 872.841381] piix4_smbus :00:01.3: no hotplug settings from platform [ 872.841384] piix4_smbus :00:01.3: using default PCI settings [ 872.841434] virtio-pci :00:03.0: no hotplug settings from platform [ 872.841436] virtio-pci :00:03.0: using default PCI settings [ 872.841510] virtio-pci :00:04.0: no hotplug settings from platform [ 872.841513] virtio-pci :00:04.0: using default PCI settings [ 872.841563] virtio-pci :00:05.0: no hotplug settings from platform [ 872.841566] virtio-pci :00:05.0: using default PCI settings [ 872.841615] virtio-pci :00:07.0: no hotplug settings from platform [ 872.841617] virtio-pci :00:07.0: using default PCI settings [ 872.841666] virtio-pci :00:02.0: no hotplug settings from platform [ 872.841669] virtio-pci :00:02.0: using default PCI settings [ 872.841756] pci :00:00.0: no hotplug settings from platform [
Bug#773286: It looks like a conspiracy between libvirt and kvm
I've restarted my VM and tried again.
This is what I see:
adriatic:~# lsof /dev/md124
adriatic:~# virsh attach-device cedric.CalvaEDI.COM zz.xml
error: Failed to attach device from zz.xml
error: internal error unable to execute QEMU command 'device_add': Bus
'pci.0' does not support hotplugging
adriatic:~# lsof /dev/md124
COMMAND PID USER FD TYPE DEVICE SIZE/OFFNODE NAME
kvm 30592 libvirt-qemu 28u BLK 9,124 0x3a3797b 4608551
/dev/md124
adriatic:~#
So libvirt doesn't think the device has been attached, but kvm has
opened it. Nothing seems to have happened in the guest (running 3.16
backport).
Here's what libvirt tried to do:
5302 write(21,
{\execute\:\drive_add\,\arguments\:{\pci_addr\:\dummy\,\opts\:\file=/dev/disk/by-id/md-name-cedric:new,if=none,id=drive-virtio-disk3,format=raw,cache=none\},\id\:\libvirt-7\}\r\n,
176) = 176
5302 read(21, {\id\: \libvirt-7\, \error\: {\class\:
\CommandNotFound\, \desc\: \The command drive_add has not been
found\, \data\: {\name\: \drive_add\}}}\r\n, 1023) = 143
5302 read(21, 0x7f31a4247b3f, 880) = -1 EAGAIN (Resource
temporarily unavailable)
5302 write(21,
{\execute\:\human-monitor-command\,\arguments\:{\command-line\:\drive_add
dummy
file=/dev/disk/by-id/md-name-cedric:new,if=none,id=drive-virtio-disk3,format=raw,cache=none\},\id\:\libvirt-8\}\r\n,
193) = 193
5302 read(21, {\return\: \OK\\r\\n\, \id\: \libvirt-8\}\r\n,
1023) = 41
5302 read(21, 0xa220d9, 982) = -1 EAGAIN (Resource
temporarily unavailable)
5302 write(21,
{\execute\:\device_add\,\arguments\:{\driver\:\virtio-blk-pci\,\scsi\:\off\,\bus\:\pci.0\,\addr\:\0x8\,\drive\:\drive-virtio-disk3\,\id\:\virtio-disk3\},\id\:\libvirt-9\}\r\n,
172) = 172
5302 read(21, {\id\: \libvirt-9\, \error\: {\class\:
\BusNoHotplug\, \desc\: \Bus 'pci.0' does not support
hotplugging\, \data\: {\bus\: \pci.0\}}}\r\n, 1023) = 135
So first it tries drive_add, which is an unknown command.
Then it tries human-monitor-command drive_add, which seems to work,
but has no effect on the guest
Then, even though the human-monitor-command worked it tries
device_add, which fails, possibly because the human-monitor-command
drive_add added something with the same id.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286: It looks like a conspiracy between libvirt and kvm
Hello John. It looks like you're making too much conspiracy theories out of this simple problem. I don't remember how this worked in 1.1 times of qemu. Apparently libvirt chooses -nodefaults and the result is that the pci bus created does not support hotplug, since libvirt didn't specify if qemu should enable that property or not. The fact that the operation is half-worked is a bug indeed -- qemu should clean up on the error path. It opens the device first and only when it's done, it tries to hotplug it, to discover that the pci bus does not support hotplugging. And it forgets to close the device. This is a bug, but a minor one, and it is fixed long ago in subsequent versions of qemu. Now, everything works fine with more recent versions of libvirt and qemu. At least 2.1 version of qemu which is available in wheezy-backports for a very long time works fine with libvirt from wheezy-backports. I haven't looked at the details and have no idea where this bug has been fixed, but I suspect it is libvirt, not qemu, since with -nodefaults qemu should explicitly specify hotpluggable attribute. One more possibility is that it is the guest OS who should have proper drivers for hotplug to be enabled, so by default PCI bus does not support hotplug, in order to not confuse an unsuspecting OS, and allows hotplugging only after an OS (guest in this case) driver enables this feature. I don't remember, this is a pure speculation, because it's been long ago since I looked at this, and even when it was only a brief look. So, basic recommendation is to check if your guest actually enables hotplug (if that's needed), and try with a more recent version. It definitely works with current qemu libvirt. So, I've no other choice but to just close this bug report. I'll keep it open for a while just in case. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773286: qemu-kvm: attemt to attach block device fails Bus 'pci.0' does not support hotplugging
Package: qemu-kvm Version: 1.1.2+dfsg-6+deb7u6 Severity: normal Dear Maintainer, * What led up to the situation? Tried to add a new disk to a running kvm guest * What exactly did you do (or not do) that was effective (or ineffective)? Using the virsh attach-device command I tried to add a new disk * What was the outcome of this action? # virsh attach-device cedric.CalvaEDI.COM zz.xml error: Failed to attach device from zz.xml error: internal error unable to execute QEMU command 'device_add': Bus 'pci.0' does not support hotplugging * What outcome did you expect instead? Happiness. The running vm looks like: /usr/bin/kvm -S -M pc-1.1 -enable-kvm -m 8192 -smp 1,sockets=1,cores=1,threads=1 -name cedric.CalvaEDI.COM -uuid 99cfca83-cf28-ce9b-86a4-947debc202b5 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/cedric.CalvaEDI.COM.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -no-acpi -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/dev/disk/by-id/md-name-cedric:root,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/dev/disk/by-id/md-name-belgic:archive,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -drive file=/dev/disk/by-id/md-name-belgic:backups,if=none,id=drive-virtio-disk2,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk2,id=vir! tio-disk2 -netdev tap,fd=20,id=hostnet0,vhost=on,vhostfd=21 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:65:2d:8e,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 Or, in libvirt xml format: domain type='kvm' id='3' namecedric.CalvaEDI.COM/name uuid99cfca83-cf28-ce9b-86a4-947debc202b5/uuid memory unit='KiB'8388608/memory currentMemory unit='KiB'4194304/currentMemory vcpu placement='static'1/vcpu os type arch='x86_64' machine='pc-1.1'hvm/type boot dev='hd'/ /os clock offset='utc' adjustment='reset'/ on_poweroffdestroy/on_poweroff on_rebootrestart/on_reboot on_crashrestart/on_crash devices emulator/usr/bin/kvm/emulator disk type='block' device='disk' driver name='qemu' type='raw' cache='none'/ source dev='/dev/disk/by-id/md-name-cedric:root'/ target dev='vda' bus='virtio'/ alias name='virtio-disk0'/ address type='pci' domain='0x' bus='0x00' slot='0x04' function='0x0'/ /disk disk type='block' device='disk' driver name='qemu' type='raw'/ source dev='/dev/disk/by-id/md-name-belgic:archive'/ target dev='vdb' bus='virtio'/ alias name='virtio-disk1'/ address type='pci' domain='0x' bus='0x00' slot='0x05' function='0x0'/ /disk disk type='block' device='disk' driver name='qemu' type='raw'/ source dev='/dev/disk/by-id/md-name-belgic:backups'/ target dev='vdc' bus='virtio'/ alias name='virtio-disk2'/ address type='pci' domain='0x' bus='0x00' slot='0x06' function='0x0'/ /disk controller type='usb' index='0' alias name='usb0'/ address type='pci' domain='0x' bus='0x00' slot='0x01' function='0x2'/ /controller interface type='bridge' mac address='00:16:3e:65:2d:8e'/ source bridge='calvaedi'/ target dev='vnet0'/ model type='virtio'/ alias name='net0'/ address type='pci' domain='0x' bus='0x00' slot='0x03' function='0x0'/ /interface serial type='pty' source path='/dev/pts/0'/ target port='0'/ alias name='serial0'/ /serial console type='pty' tty='/dev/pts/0' source path='/dev/pts/0'/ target type='serial' port='0'/ alias name='serial0'/ /console memballoon model='virtio' alias name='balloon0'/ address type='pci' domain='0x' bus='0x00' slot='0x07' function='0x0'/ /memballoon /devices seclabel type='none'/ /domain The device I tried to add looks like: disk type='block' device='disk' driver name='qemu' type='raw' cache='none'/ source dev='/dev/disk/by-id/md-name-cedric:new'/ target dev='vdd' bus='virtio'/ /disk The error in libvirtd.log is: 2014-12-16 13:22:50.831+: 5305: error : qemuMonitorJSONCheckError:342 : internal error unable to execute QEMU command 'device_add': Bus 'pci.0' does not support hotplugging 2014-12-16 13:22:50.832+: 5305: warning : qemuDomainAttachPciDiskDevice:255 : qemuMonitorAddDevice failed on file=/dev/disk/by-id/md-name-cedric:new,if=none,id=drive-virtio-disk3,format=raw,cache=none (virtio-blk-pci,scsi=off,bus=pci.0,addr=0xb,drive=drive-virtio-disk3,id=virtio-disk3) From strace it seems that the commands
Bug#773286: qemu-kvm: attemt to attach block device fails Bus 'pci.0' does not support hotplugging
Well, it looks like the command has half worked -- lsof shows me that kvm has opened the block device I tried to add. Now how to make it give it up? # lsof /dev/md/cedric\:new COMMAND PID USER FD TYPE DEVICE SIZE/OFFNODE NAME kvm 28159 libvirt-qemu 28u BLK 9,124 0x3a3797b 4608551 /dev/md/../md124 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
