RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1951814 - RFE: Warning when using qcow2-v2 (compat=0.10)
Summary: RFE: Warning when using qcow2-v2 (compat=0.10)
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: qemu-kvm
Version: 9.0
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: beta
: ---
Assignee: Kevin Wolf
QA Contact: Tingting Mao
Jiri Herrmann
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-20 21:38 UTC by Ademar Reis
Modified: 2021-12-07 22:40 UTC (History)
13 users (show)

Fixed In Version: qemu-kvm-6.0.0-13.el9
Doc Type: Deprecated Functionality
Doc Text:
.qcow2-v2 image format is deprecated With RHEL 9, the qcow2-v2 format for virtual disk images has become deprecated, and will become unsupported in a future major release of RHEL. In addition, the RHEL 9 Image Builder cannot create disk images in the qcow2-v2 format. Instead of qcow2-v2, Red Hat strongly recommends using qcow2-v3. To convert a qcow2-v2 image to a later format version, use the `qemu-img amend` command.
Clone Of:
Environment:
Last Closed: 2021-12-07 21:20:54 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat/centos-stream/src qemu-kvm merge_requests 37 0 None None None 2021-08-20 18:32:02 UTC

Description Ademar Reis 2021-04-20 21:38:48 UTC
There are two main versions of qcow2 images:

The newer version, with better performance and robustness is what we strongly recommend to be used in production. This version is sometimes called "qcow2-v3" or "compat=1.1". It's the default in qemu-img and was introduced in QEMU-1.1, from June of 2012.

But there's also qcow2-v2, which is created with the compatibility flag compat=0.10.

This BZ asks for qcow2-v2 (the old format) to be enabled as read-only. This will prevent the creation use of legacy images while still allowing their limited use.

Pros:
 - Reduce usage of this legacy format, including whoever is using it by accident or due to inertia.
   -- This has benefits like performance and robustness.
 - Simplify our test-matrix
 - Reduce the attack surface

Cons:
 - RHEL-6 is in EUS and doesn't support the use of qcow2-v3 images (qemu-0.12). Images created in RHEL-9 will not run on RHEL-6.
 - The qcow2 images distributed by Red Hat are currently created with compat=0.10. See https://projects.engineering.redhat.com/browse/RHELBLD-664


Users will still be able to convert old images to the new format with a qemu-img convert command.

Comment 5 Klaus Heinrich Kiwi 2021-06-29 17:21:59 UTC
Help me identify where this discussion is headed.. Would it be fair to say it's doable to:

1) Build Qemu with read-only support for qcow2-v2, read-write support for qcow2-v3+ (whitelist switches)

2) Do that only for Qemu, without affecting the ability of qemu-image to write/amend/convert qcow2-v2 images

3) Document that qcow2-v2 is being deprecated in RHEL9, and cannot be used as an option for running production workloads any longer. Still, qemu-img could be used to convert them (document those steps)

Comment 6 Klaus Heinrich Kiwi 2021-06-29 17:40:33 UTC
Looks like the upstream discussion converged? Can we expect a POST soon Eric?

Comment 12 Klaus Heinrich Kiwi 2021-08-19 19:13:22 UTC
Kevin,

 can you give us an update / ETA on the downstream changes to log v2 usage? I'm setting dev_ack and DTM/ITM targets, let me know if they are not realistic.

Comment 16 Tingting Mao 2021-08-27 09:53:00 UTC
Hi Kevin,

When I verified this bug as below. I noticed that booting a guest from the qcow2 image with 0.10 compat, there is warnings as expected. But did some tests related to 'qemu-img', ther is no warnings. 

I think there should also be warnings of 'qemu-img' related CMLs for the consistency. What do you think? Maybe a new bug for it?



Tested with:
qemu-kvm-6.0.0-13.el9
kernel-modules-5.14.0-0.rc6.46.el9.x86_64


Scenario1 -- Boot up a guest from a qcow2 image with 0.10 compat.
1. Create a qcow2 image with 0.10 compat
# qemu-img create -f qcow2 -o compat=0.10 test.qcow2 2G

2. Boot up a guest from the image
/usr/libexec/qemu-kvm \
......
......
    -device pcie-root-port,id=pcie-root-port-5,port=0x5,addr=0x1.0x5,bus=pcie.0,chassis=5 \
    -device virtio-scsi-pci,id=virtio_scsi_pci1,bus=pcie-root-port-5,addr=0x0,iothread=iothread1 \
    -blockdev node-name=nvme_image1,driver=file,filename=$1,auto-read-only=on,discard=unmap \
    -blockdev node-name=drive_nvme1,driver=qcow2,file=nvme_image1,read-only=off,discard=unmap \
    -device scsi-hd,id=nvme1,drive=drive_nvme1 \

Results:
qemu-kvm: -blockdev node-name=drive_nvme1,driver=qcow2,file=nvme_image1,read-only=off,discard=unmap: warning: qcow2 v2 images are deprecated and may not be supported in future versions. Please consider upgrading the image with 'qemu-img amend -o compat=v3'. ------------------------------------------------------> Warning here.
QEMU 6.0.0 monitor - type 'help' for more information
(qemu) 



Scenario2 -- Tests related to 'qemu-img' of a qcow2 image with 0.10 compat.
1. Create a qcow2 image with 0.10 compat
# qemu-img create -f qcow2 -o compat=0.10 test.qcow2 2G
Formatting 'test.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off compression_type=zlib size=2147483648 compat=0.10 lazy_refcounts=off refcount_bits=16 ---------> Success without warnings

2. Amend the version of a qcow2 image with 1.1 compat to 0.10
# qemu-img create -f qcow2 test.qcow2_v3 3G
# qemu-img amend -o compat=v2 -f qcow2 test.qcow2_v3 
# echo $? 
0 -------------------------------------------------------------------------> Success without warnings
Or
# qemu-img create -f qcow2 test.qcow2_v3 3G
# qemu-img amend -o compat=0.10 -f qcow2 test.qcow2_v3 
# echo $? 
0 -------------------------------------------------------------------------> Success without warnings

3. Convert a image to qcow2 image with 0.10 compat
# qemu-img create -f raw test.img 2G
# qemu-img convert -f raw -O qcow2 -o compat=0.10 test.img tgt.qcow2
# echo $? 
0 -------------------------------------------------------------------------> Success without warnings



Best,
Tingting

Comment 17 Yanan Fu 2021-08-30 05:37:28 UTC
QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.

Comment 20 Tingting Mao 2021-08-30 07:20:59 UTC
According to comment 16, set this bug as verified. Will file a new bug if needed.

Comment 23 Kevin Wolf 2021-09-08 10:48:30 UTC
(In reply to Tingting Mao from comment #16)
> When I verified this bug as below. I noticed that booting a guest from the
> qcow2 image with 0.10 compat, there is warnings as expected. But did some
> tests related to 'qemu-img', ther is no warnings. 

I intentionally decided not to print warnings in tools because otherwise, even upgrading from v2 to v3 with 'qemu-img amend' would print a warning, which would be confusing. The same is true when you explicitly requested creating an image with the old version, e.g. to export an image to an old QEMU version. The relevant case to warn about is when users don't only create images, but actually use them to run VMs, and then they will get the warning either way.


Note You need to log in before you can comment on or make changes to this bug.