Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1728461

Summary: qemu gets ABRT when attach a existing qcow2 disk and then detach it
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Han Han <hhan>
Component: qemu-kvmAssignee: Ademar Reis <areis>
Status: CLOSED DUPLICATE QA Contact: CongLi <coli>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.1CC: coli, dyuan, fjin, hreitz, jgao, jinzhao, juzhang, ngu, ribarry, virt-maint, xuzhang, yafu, yisun
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1728459 Environment:
Last Closed: 2019-07-11 01:45:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1722090, 1728459    
Bug Blocks:    

Description Han Han 2019-07-10 03:31:37 UTC 
+++ 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.
Comment 1 CongLi 2019-07-10 03:33:23 UTC 

*** This bug has been marked as a duplicate of bug 1529454 ***
Comment 3 Hanna Czenczek 2019-07-10 13:50:03 UTC 
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
Comment 5 CongLi 2019-07-11 01:45:21 UTC 
(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 ***