Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1786403 - [Regression]The virt-sparsify command fails when handling the qcow2 image
Summary: [Regression]The virt-sparsify command fails when handling the qcow2 image
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libguestfs
Version: 8.2
Hardware: x86_64
OS: Unspecified
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Richard W.M. Jones
QA Contact: YongkuiGuo
URL:
Whiteboard:
Depends On: 1798148 1801219
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-12-25 03:24 UTC by YongkuiGuo
Modified: 2020-07-03 04:15 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-03 04:15:08 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
virt-sparsify log (63.07 KB, text/plain)
2019-12-25 03:30 UTC, YongkuiGuo 		no flags Details
View All

Description YongkuiGuo 2019-12-25 03:24:07 UTC 
Description of problem:
The virt-sparsify command fails when handling the qcow2 image on RHEL-AV compose.


Version-Release number of selected component (if applicable):
libguestfs-1.40.2-14.module+el8.2.0+4793+b09dd2fb.x86_64
qemu-kvm-4.2.0-4.module+el8.2.0+5220+e82621dc.x86_64
kernel-4.18.0-160.el8.x86_64


How reproducible:
100%


Steps:

1. Install RHEL-AV related packages on rhel8.2 host

2.
# qemu-img create -f qcow2 virt_tools.xfs.qcow2 200M

3.
# guestfish -a virt_tools.xfs.qcow2
><fs> run
><fs> pvcreate /dev/sda
><fs> vgcreate vol_test /dev/sda
><fs> lvcreate vol_file vol_test 190
><fs> mkfs xfs /dev/vol_test/vol_file
><fs> vfs_type /dev/vol_test/vol_file
xfs
><fs> mount /dev/vol_test/vol_file /
><fs> fill 1 93519872 /test
><fs> sync
><fs> rm /test
><fs> quit

4.
# qemu-img info virt_tools.xfs.qcow2
image: virt_tools.xfs.qcow2
file format: qcow2
virtual size: 200 MiB (209715200 bytes)
disk size: 95.4 MiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

5.
# virt-sparsify -x -v virt_tools.xfs.qcow2 outdisk 2>&1 | tee output.log

6.
# qemu-img info outdisk
image: outdisk
file format: qcow2
virtual size: 200 MiB (209715200 bytes)
disk size: 115 MiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false


The qcow2 format image seems to not be sparsified.


Actual results:
The virt-sparsify command fails.

Expected results:
The virt-sparsify command should be able to deal with the qcow2 image successfully.


Additional info:
Comment 1 YongkuiGuo 2019-12-25 03:30:38 UTC 
Created attachment 1647576 [details]
virt-sparsify log
Comment 2 Richard W.M. Jones 2020-03-02 12:41:22 UTC 
Here's a smaller reproducer:

$ qemu-img create -f qcow2 test1.qcow2 1G
$ guestfish -a test1.qcow2 run : mkfs xfs /dev/sda : mount /dev/sda / : fill 1 100M /test : sync : rm /test
$ virt-sparsify test1.qcow2 test2.qcow2
$ file test?.qcow2
test1.qcow2: QEMU QCOW2 Image (v3), 1073741824 bytes
test2.qcow2: QEMU QCOW2 Image (v3), 1073741824 bytes
$ ls -lh test?.qcow2
-rw-r--r--. 1 rjones rjones 111M Mar  2 12:37 test1.qcow2
-rw-r--r--. 1 rjones rjones 103M Mar  2 12:37 test2.qcow2
$ du -sh test?.qcow2
111M	test1.qcow2
103M	test2.qcow2

Using this we can more easily try different formats and filesystems.

qcow2     xfs     FAILS (see above)
raw       xfs     OK
qcow2     ext4    FAILS

I was testing this with qemu-4.2.0-4.fc32.x86_64

I will need to go back to earlier versions of qemu to see if this ever worked
before / what broke it.
Comment 3 Richard W.M. Jones 2020-03-02 13:00:35 UTC 
This is weird, the bug only happens when the backend is libvirt (not direct).
export LIBGUESTFS_BACKEND=direct "fixes" it ...
Comment 4 Richard W.M. Jones 2020-03-02 15:19:08 UTC 
I couldn't find a way to reproduce this reliably.  In particular the bug
seemed to go away when I upgraded libvirt from 5.10 to 6.0.  Which
version of libvirt were you using for this test, and does it work
with the latest libvirt in RHEL AV?
Comment 5 YongkuiGuo 2020-03-03 04:10:05 UTC 
(In reply to Richard W.M. Jones from comment #3)
> This is weird, the bug only happens when the backend is libvirt (not direct).
> export LIBGUESTFS_BACKEND=direct "fixes" it ...

Thanks for providing the simpler reproducer. I have tried and indeed the virt-sparsify command works when the backend is 'direct'. 

(In reply to Richard W.M. Jones from comment #4)
> I couldn't find a way to reproduce this reliably.  In particular the bug
> seemed to go away when I upgraded libvirt from 5.10 to 6.0.  Which
> version of libvirt were you using for this test, and does it work
> with the latest libvirt in RHEL AV?

The libvirt version for test is 'libvirt-5.10.0-2.module+el8.2.0+5274+60f836b5.x86_64'. I upgraded libvirt to the latest version（libvirt-6.0.0-7.module+el8.2.0+5869+c23fe68b.x86_64）, but failed to run the virt-sparsify command because of bug 1798148. 
Did you test on fedora 32? I use RHEL8.2 bare metal for this test.
Comment 6 Richard W.M. Jones 2020-03-03 09:04:56 UTC 
(In reply to YongkuiGuo from comment #5)
> The libvirt version for test is
> 'libvirt-5.10.0-2.module+el8.2.0+5274+60f836b5.x86_64'. I upgraded libvirt
> to the latest version（libvirt-6.0.0-7.module+el8.2.0+5869+c23fe68b.x86_64）,
> but failed to run the virt-sparsify command because of bug 1798148. 
> Did you test on fedora 32? I use RHEL8.2 bare metal for this test.

I was using Fedora (Rawhide) but I had patched my copy of virt-sparsify
with a non-upstream patch[1] that fixes the bug 1798148 problem.  Because
that is not an option for RHEL, I guess we will need to wait for that other
bug to be fixed first.

[1] https://www.redhat.com/archives/libguestfs/2020-February/msg00013.html
Comment 7 YongkuiGuo 2020-03-03 09:39:56 UTC 
> I was using Fedora (Rawhide) but I had patched my copy of virt-sparsify
> with a non-upstream patch[1] that fixes the bug 1798148 problem.  Because
> that is not an option for RHEL, I guess we will need to wait for that other
> bug to be fixed first.
> 
Ok, i get it.
Comment 8 YongkuiGuo 2020-03-06 07:22:45 UTC 
Can not reproduce this issue with the latest libvirt version (libvirt-6.0.0-8, fixed version for bug 1798148).

Steps:

$ qemu-img create -f qcow2 test1.qcow2 1G
$ guestfish -a test1.qcow2 run : mkfs xfs /dev/sda : mount /dev/sda / : fill 1 100M /test : sync : rm /test
$ virt-sparsify test1.qcow2 test2.qcow2
$ du -sh test?.qcow2 
114M	test1.qcow2
4.2M	test2.qcow2
Comment 9 Richard W.M. Jones 2020-07-02 18:35:39 UTC 
So I also believe this is now fixed (I'm using libvirt-6.3.0-1.module+el8.3.0+6478+69f490bb.x86_64)

Can we close this bug?
Comment 10 YongkuiGuo 2020-07-03 00:09:36 UTC 
(In reply to Richard W.M. Jones from comment #9)
> So I also believe this is now fixed (I'm using
> libvirt-6.3.0-1.module+el8.3.0+6478+69f490bb.x86_64)
> 
> Can we close this bug?

Yes, I think we can close it.
Note You need to log in before you can comment on or make changes to this bug.