Description of problem: Failed to delete virtio-blk device by "device_del" Version-Release number of selected component (if applicable): kernel version: 3.10.0-826.el7.x86_64 qemu-kvm-rhev version: qemu-kvm-rhev-2.10.0-16.el7.x86_64 How reproducible: 98% Steps to Reproduce: 1.Start guest with virtio-blk data disk, cmds as bellow: /usr/libexec/qemu-kvm \ -sandbox off \ -machine pc \ -nodefaults \ -vga cirrus \ -chardev socket,id=qmp_id_qmpmonitor1,path=/var/tmp/monitor-qmpmonitor1-20170614-233639-etu9X2zc,server,nowait \ -mon chardev=qmp_id_qmpmonitor1,mode=control \ -chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/monitor-catch_monitor-20170614-233639-etu9X2zc,server,nowait \ -mon chardev=qmp_id_catch_monitor,mode=control \ -device pvpanic,ioport=0x505,id=idhq2DAN \ -chardev socket,id=serial_id_serial0,path=/var/tmp/serial-serial0-20170614-233639-etu9X2zc,server,nowait \ -device isa-serial,chardev=serial_id_serial0 \ -chardev socket,id=seabioslog_id_20170614-233639-etu9X2zc,path=/var/tmp/seabios-20170614-233639-etu9X2zc,server,nowait \ -device isa-debugcon,chardev=seabioslog_id_20170614-233639-etu9X2zc,iobase=0x402 \ -device ich9-usb-ehci1,id=usb1,addr=0x1f.7,multifunction=on,bus=pci.0 \ -device ich9-usb-uhci1,id=usb1.0,multifunction=on,masterbus=usb1.0,addr=0x1f.0,firstport=0,bus=pci.0 \ -device ich9-usb-uhci2,id=usb1.1,multifunction=on,masterbus=usb1.0,addr=0x1f.2,firstport=2,bus=pci.0 \ -device ich9-usb-uhci3,id=usb1.2,multifunction=on,masterbus=usb1.0,addr=0x1f.4,firstport=4,bus=pci.0 \ -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/kvm_autotest_root/images/win10-64-virtio.qcow2 \ -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x3 \ -drive id=drive_data1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=/home/aliang.img \ -device virtio-blk-pci,id=data1,drive=drive_data1 \ -device virtio-net-pci,mac=9a:43:44:45:46:47,id=idvMp6XX,vectors=4,netdev=id9qJxPT,bus=pci.0 \ -netdev tap,id=id9qJxPT,vhost=on \ -m 4096 \ -smp 6,cores=2,threads=1,sockets=3 \ -cpu host,+kvm_pv_unhalt,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time \ -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 \ -vnc :0 \ -rtc base=utc,clock=host,driftfix=slew \ -boot order=cdn,once=d,menu=off,strict=off \ -no-shutdown \ -enable-kvm \ -monitor stdio \ -spice ipv4,port=5000,disable-ticketing \ 2. Check disk info: (qemu) info block drive_image1 (#block145): /home/kvm_autotest_root/images/win10-64-virtio.qcow2 (qcow2) Attached to: /machine/peripheral/image1/virtio-backend Cache mode: writeback, direct drive_data1 (#block314): /home/aliang.img (qcow2) Attached to: /machine/peripheral/data1/virtio-backend Cache mode: writeback, direct 3. Delete data disk by qmp cmd: {"execute":"device_del","arguments":{"id":"data1"}} 4. Wait one minute, then check disk info (qemu) info block drive_image1 (#block145): /home/kvm_autotest_root/images/win10-64-virtio.qcow2 (qcow2) Attached to: /machine/peripheral/image1/virtio-backend Cache mode: writeback, direct drive_data1 (#block314): /home/aliang.img (qcow2) Attached to: /machine/peripheral/data1/virtio-backend Cache mode: writeback, direct Actual results: No "DEVICE_DELETE" event sent out, and data disk is not unplugged. Expected results: Data disk can be plugged successfully. Additional info: When loading data disk as scsi-hd, it can be unplugged successfully.
Test on qemu-kvm-rhev-2.10.0-17.el7, hit the same issue.
Appears to be related (or even a duplicate of) Bug 1530577
Not a regression bug.
Since 1530577 is already fixed, does this issue exist on the latest kernel?
yes, fam, the same issue exist. Test steps: 1. Start guest, during its running stage before "Welcome to Red Hat Enterprise xxx", execute "device_del" 2. Check block info (qemu) info block ---> data disk is still there 3. Reboot guest by "system_reset", then check block info (qemu) info block ---> data disk is removed So, i am not sure if it's normal? or a bug?
Guest in the early boot stage may not be ready to answer the unplug request issued by QEMU (via ACPI). So this is not a bug.
Got it, thank you, fam