Bug 1845518
Summary: | qemu-img convert to preallocated image makes it sparse | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 9 | Reporter: | Xiaodai Wang <xiaodwan> |
Component: | virt-v2v | Assignee: | Virtualization Maintenance <virt-maint> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | unspecified | CC: | juzhou, lersek, mxie, mzhan, ptoscano, rjones, tyan, tzheng |
Target Milestone: | beta | Keywords: | Automation, Regression, Reopened, Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2022-05-16 09:58:39 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: | |||
Bug Blocks: | 1897025 |
Description
Xiaodai Wang
2020-06-09 12:34:18 UTC
This problem turned up in the virt-v2v test suite around the end of last year. To summarise what's happening briefly: When using the -oa preallocated option we want to create a fully allocated guest. To do this we do something like this: (a) qemu-img create [the output] -o preallocation=falloc,compat=1.1 (b) qemu-img convert [the source] [the output] In versions of qemu before commit 4d7c487eac1652dfe4498fe84f32900ad461d61b the copy operation (b) would preserve the fully allocated state of the output. However after this commit qemu-img actually trims the output when it sees sparseness in the input, making the output sparse. Upstream added a --target-is-zero option which I believe can be used to fix this. However we mustn't add it unconditionally. There are some corner cases where we cannot guarantee that the target is really zero, eg. if writing to a block device. I have confirmed that --target-is-zero does fix the example that I gave in the qemu-devel mailing list link above. *** Bug 1791831 has been marked as a duplicate of this bug. *** The long term plan to fix this is by using nbdcopy. See: https://listman.redhat.com/archives/libguestfs/2020-November/msg00022.html https://bugzilla.redhat.com/show_bug.cgi?id=1798105 I can reproduce this bug when using virt-v2v to convert guest to RHV export domain. Version: virt-v2v-1.44.0-1.el9.1.x86_64 libguestfs-1.45.6-1.el9.x86_64 qemu-kvm-6.0.0-2.el9.x86_64 libvirt-7.3.0-1.el9.x86_64 nbdkit-1.25.7-1.el9.x86_64 Steps: 1. Convert a guest with raw sparse disk using -oa preallocated -of raw. # virt-v2v -i libvirt rhel8-raw -o rhv -os 10.73.224.195:/home/nfs_export --network ovirtmgmt -oa preallocated -of raw [ 0.0] Opening the source -i libvirt rhel8-raw [ 0.0] Creating an overlay to protect the source from being modified [ 0.1] Opening the overlay [ 4.5] Inspecting the overlay [ 7.7] Checking for sufficient free disk space in the guest [ 7.7] Estimating space required on target for each disk [ 7.7] Converting Red Hat Enterprise Linux 8.5 Beta (Ootpa) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 59.2] Mapping filesystem data to avoid copying unused and blank areas [ 60.2] Closing the overlay [ 60.5] Assigning disks to buses [ 60.5] Checking if the guest needs BIOS or UEFI to boot [ 60.5] Initializing the target -o rhv -os 10.73.224.195:/home/nfs_export [ 60.7] Copying disk 1/1 to /tmp/v2v.ewvDSB/91804183-2de6-48ab-a6fb-e82d501a36c7/images/763f550e-8411-40f8-94ea-8b1ed3480994/87e4802f-f4f6-4b53-8bd5-4061dd07beca (raw) (100.00/100%) [ 126.8] Creating output metadata virt-v2v: warning: oVirt cannot emulate ‘ich9’ sound cards. This sound card will be dropped from the output. [ 126.9] Finishing off 2. After v2v runs successfully, mount RHV export domain to check the disk format. #mount 10.73.224.195:/home/nfs_export /mnt/ # qemu-img info /mnt/91804183-2de6-48ab-a6fb-e82d501a36c7/images/763f550e-8411-40f8-94ea-8b1ed3480994/87e4802f-f4f6-4b53-8bd5-4061dd07beca image: /mnt/91804183-2de6-48ab-a6fb-e82d501a36c7/images/763f550e-8411-40f8-94ea-8b1ed3480994/87e4802f-f4f6-4b53-8bd5-4061dd07beca file format: raw virtual size: 10 GiB (10737418240 bytes) disk size: 2.86 GiB 3.Check disk metadata # cat /mnt/91804183-2de6-48ab-a6fb-e82d501a36c7/images/763f550e-8411-40f8-94ea-8b1ed3480994/87e4802f-f4f6-4b53-8bd5-4061dd07beca.meta DOMAIN=91804183-2de6-48ab-a6fb-e82d501a36c7 VOLTYPE=LEAF CTIME=1622708875 MTIME=1622708875 IMAGE=763f550e-8411-40f8-94ea-8b1ed3480994 DISKTYPE=2 PUUID=00000000-0000-0000-0000-000000000000 LEGALITY=LEGAL POOL_UUID= SIZE=20971520 FORMAT=RAW TYPE=PREALLOCATED DESCRIPTION=generated by virt-v2v 1.44.0rhel_9,release_1.el9.1 EOF After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. This bug was closed in error by a process that we have no control over. I am reopening it. Xiaodai - this should be fixed by virt-v2v >= 1.45.9x Can you please retest -- the latest virt-v2v uses nbdcopy and should not have this problem (per comment 5 and comment 11). I tried the conversion of this bug in RHEL9.1, the disk size is correct now. # qemu-img info xen-hvm-rhel7.8-x86_64-sda image: xen-hvm-rhel7.8-x86_64-sda file format: qcow2 virtual size: 8.79 GiB (9437184000 bytes) disk size: 8.79 GiB cluster_size: 65536 Format specific information: compat: 1.1 compression type: zlib lazy refcounts: false refcount bits: 16 corrupt: false extended l2: false and nbdcopy is used during copying process. so I think this bug can be closed as CURRENTRELEASE. Thanks for retesting this. I'm closing currentrelease per comment 13. |