Bug 1951814

Summary:	RFE: Warning when using qcow2-v2 (compat=0.10)
Product:	Red Hat Enterprise Linux 9	Reporter:	Ademar Reis <areis>
Component:	qemu-kvm	Assignee:	Kevin Wolf <kwolf>
qemu-kvm sub component:	qcow2	QA Contact:	Tingting Mao <timao>
Status:	CLOSED CURRENTRELEASE	Docs Contact:	Jiri Herrmann <jherrman>
Severity:	medium
Priority:	high	CC:	coli, eblake, hreitz, jinzhao, juzhang, kchamart, kkiwi, kwolf, mrezanin, timao, virt-maint, wshi, xuwei
Version:	9.0	Keywords:	FutureFeature, RFE, Triaged
Target Milestone:	beta	Flags:	pm-rhel: mirror+
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-12-07 21:20:54 UTC	Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.