+++ This bug was initially created as a clone of Bug #1728459 +++ Description of problem: As subject Version-Release number of selected component (if applicable): libvirt-4.5.0-23.virtcov.el7.x86_64 qemu-kvm-rhev-2.12.0-33.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Start a vm. 2. Attach a qcow2 disk with target vdb # virsh attach-disk PC /tmp/a.qcow2 vdb --subdriver qcow2 Disk attached successfully 3. Attach the same disk with another target # virsh attach-disk PC /tmp/a.qcow2 vdc --subdriver qcow2 error: Failed to attach disk error: internal error: unable to execute QEMU command '__com.redhat_drive_add': Device 'drive-virtio-disk2' could not be initialized 4. Detach the disk # virsh detach-disk PC /tmp/a.qcow2 error: Failed to detach disk error: Unable to read from monitor: Connection reset by peer Qemu gets SIGABRT Actual results: As above Expected results: No SIGABRT Additional info: Reproduced on libvirt-5.5.0-1.module+el8.1.0+3580+d7f6488d.x86_64 qemu-kvm-4.0.0-5.module+el8.1.0+3622+5812d9bf.x86_64 No reproduced with raw disk: # virsh attach-disk PC /tmp/a.raw vdb # virsh attach-disk PC /tmp/a.raw vdc # virsh detach-disk PC /tmp/a.raw See the all threads backtrace in gdb.txt. --- Additional comment from RHEL Product and Program Management on 2019-07-10 03:16:21 UTC --- Since this bug report was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release.
*** This bug has been marked as a duplicate of bug 1529454 ***
The backtrace certainly looks like it, but the problem is that I cannot reproduce the problem at all with upstream libvirt (neither with qemu-kvm-rhev-2.12.0-33.el7 nor with qemu-kvm-4.0.0-5.module+el8.1.0+3622+5812d9bf). I’m trying to get a downstream version running, but no luck so far. I mean, I can do this for RHV 7: $ qemu-img create -f qcow2 /tmp/a.qcow2 64M; \ (echo "{'execute':'qmp_capabilities'} {'execute':'__com.redhat_drive_add', 'arguments':{'id':'drv0','file':'/tmp/a.qcow2','driver':'qcow2'}}"; sleep 1; rm /tmp/a.qcow2; echo "{'execute':'__com.redhat_drive_del', 'arguments':{'id':'drv0'}}") \ | $RHV7_QEMU -qmp stdio Formatting '/tmp/a.qcow2', fmt=qcow2 size=67108864 cluster_size=65536 lazy_refcounts=off refcount_bits=16 {"QMP": {"version": {"qemu": {"micro": 0, "minor": 12, "major": 2}, "package": "v2.12.0-917-gdd55d8a500"}, "capabilities": []}} {"return": {}} {"return": {}} Unexpected error in raw_reconfigure_getfd() at block/file-posix.c:903: Could not reopen file: No such file or directory [1] 23320 done ( echo ; sleep 1; rm /tmp/a.qcow2; echo ; ) | 23321 abort (core dumped) $RHV7_QEMU -qmp stdio But the difference is that I delete the file in between. In any case, that would be the same as BZ 1722090. Now, for RHEL 8 AV, the corresponding BZ is BZ 1709791. The problem described in BZ 1529454 should actually be fixed already, compare BZ 1529454 comment 29. Max
(In reply to Max Reitz from comment #3) > The backtrace certainly looks like it, but the problem is that I cannot > reproduce the problem at all with upstream libvirt (neither with > qemu-kvm-rhev-2.12.0-33.el7 nor with > qemu-kvm-4.0.0-5.module+el8.1.0+3622+5812d9bf). I’m trying to get a > downstream version running, but no luck so far. > > I mean, I can do this for RHV 7: > > $ qemu-img create -f qcow2 /tmp/a.qcow2 64M; \ > (echo "{'execute':'qmp_capabilities'} > {'execute':'__com.redhat_drive_add', > 'arguments':{'id':'drv0','file':'/tmp/a.qcow2','driver':'qcow2'}}"; > sleep 1; > rm /tmp/a.qcow2; > echo "{'execute':'__com.redhat_drive_del', > 'arguments':{'id':'drv0'}}") \ > | $RHV7_QEMU -qmp stdio > Formatting '/tmp/a.qcow2', fmt=qcow2 size=67108864 cluster_size=65536 > lazy_refcounts=off refcount_bits=16 > {"QMP": {"version": {"qemu": {"micro": 0, "minor": 12, "major": 2}, > "package": "v2.12.0-917-gdd55d8a500"}, "capabilities": []}} > {"return": {}} > {"return": {}} > Unexpected error in raw_reconfigure_getfd() at block/file-posix.c:903: > Could not reopen file: No such file or directory > [1] 23320 done ( echo ; sleep 1; rm /tmp/a.qcow2; echo ; > ) | > 23321 abort (core dumped) $RHV7_QEMU -qmp stdio > > But the difference is that I delete the file in between. In any case, that > would be the same as BZ 1722090. > > > Now, for RHEL 8 AV, the corresponding BZ is BZ 1709791. The problem > described in BZ 1529454 should actually be fixed already, compare BZ 1529454 > comment 29. > > Max Thanks Max for the confirmation. Close this bug as a dup to BZ1709791. *** This bug has been marked as a duplicate of bug 1709791 ***