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: | --- | Flags: | pm-rhel:
mirror+
|
| 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. |