Description of problem: can not get block stats from attached disks. Version-Release number of selected component (if applicable): from 0.6.1 to 0.9.1 [root@bc-clc vms]# virsh version Compiled against library: libvir 0.9.1 Using library: libvir 0.9.1 Using API: QEMU 0.9.1 Running hypervisor: QEMU 0.9.1 [root@bc-clc vms]# rpm -qa|grep kvm kmod-kvm-83-224.el5.centos.1 kvm-qemu-img-83-224.el5.centos.1 etherboot-zroms-kvm-5.4.4-13.el5.centos kvm-83-224.el5.centos.1 How reproducible: 1.create a vm: virsh create libvirt.xml 2.attach a disk:virsh attach-disk 3 /opt/vms/test.img vdb 3.virsh domblkstats 3 vdb error: Failed to get block stats 3 vdb error: internal error missing disk device alias name for vdb 4.while virsh domblkstats 3 vda vda rd_req 6667 vda rd_bytes 154084864 vda wr_req 9530 vda wr_bytes 57196544 Additional info: I guess,libvirt does not get disk->info.alias while attching a disk.
Created attachment 503833 [details] the vm libvirt xml file
Can you test with debug log level turned on? when you attached the disk, you should see the "device string" which is constructed by libvirt in debug log: VIR_DEBUG("mon=%p device=%s fd=%d fdname=%s", mon, devicestr, fd, NULLSTR(fdname)); E.g. device=virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk1,id=virtio-disk1 The value for "id" in the end of the string actually is the value of "disk->info.alias". It looks to me there is no reason the "disk->info.alias" is NULL, libvirt assigns its value when attaching the disk, if it fails on assigning its value, the disk attaching will fail earlier, means you won't see the disk attaching was successfull. See "log_level" in "/etc/libvirt/libvirtd.conf" for how to set the debug log level.
I changed "log_level" in ""/etc/libvirt/libvirtd.conf" as attachment. I got following logs : 11:43:13.072: 17759: debug : qemuCapsParseHelpStr:1037 : Version 0.9.1, cooked version 9001, flags 0x0000580f120efd7e 11:43:13.072: 17759: debug : qemuCapsParseHelpStr:1041 : KVM version 83 detected 11:43:13.072: 17759: info : virSecurityDACSetOwnership:99 : Setting DAC user and group on '/opt/vms/test.img' to '101:36' 11:43:13.072: 17759: debug : qemuMonitorAddPCIDisk:1715 : mon=0x12466d90 path=/opt/vms/test.img bus=virtio 11:43:13.072: 17759: debug : qemuMonitorTextCommandWithHandler:233 : Send command 'pci_add pci_addr=auto storage file=/opt/vms/test.img,if=virtio' for write with FD -1 11:43:13.072: 17759: debug : virEventPollUpdateHandle:144 : Update handle w=8 e=15
Created attachment 504366 [details] libvirt log file libvirt log file
this is log when detaching a disk ,libvirt does use pci_address ,not info.alias. 15:40:39.864: debug : virEventCalculateTimeout:314 : Calculate expiry of 2 timers 15:40:39.864: debug : virEventCalculateTimeout:344 : Timeout at 0 due in -1 ms 15:40:39.864: debug : virEventRunOnce:593 : Poll on 8 handles 0x2aaaac0015e0 timeout -1 15:40:39.864: debug : qemuMonitorRemovePCIDevice:1555 : mon=0x61c9eb0 domain=0 bus=0 slot=6 function=0 15:40:39.864: debug : qemuMonitorCommandWithHandler:338 : Send command 'pci_del pci_addr=0000:00:06' for write with FD -1 15:40:39.864: debug : virEventUpdateHandleImpl:147 : Update handle w=11 e=15 15:40:39.864: debug : virEventInterruptLocked:668 : Interrupting 15:40:39.864: debug : virEventRunOnce:595 : Poll got 1 event 15:40:39.864: debug : virEventDispatchTimeouts:405 : Dispatch 2
Oh, it looks to me your qemu doesn't support "-device" yet, that's why the final command to attach a disk is "pci_add". libvirt doesn't generate "info.alias" for the disk attaching in this case, this is a bug of libvirt indeed.
what should I do now,update kvm?
If it's urgent for you to bypass the problem, you can update your qemu to the one support "-device" flag. No need to update KVM.
(In reply to comment #6) > Oh, it looks to me your qemu doesn't support "-device" yet, that's why the > final command to attach a disk is "pci_add". libvirt doesn't generate > "info.alias" for the disk attaching in this case, this is a bug of libvirt > indeed. I think we are not likely ever to support such old versions of qemu, so I a closing as WONTFIX.