We use this for “virt-v2v -i ova” and “-i vmx” so it cannot be removed
completely.  R/O is fine of course.  And I wouldn't trust the code that
we have for writing anyway, the format is much too baroque.

(In reply to Ademar Reis from comment #0)
> The support for VMDK image format seems to be enabled as read-write in RHEL
> (see Bug #1955608). This image format is not actively maintained in upstream
> QEMU and we're not investing any resources in it.
> 
> I believe it should be supported as read-only due to conversion, but not
> read-write.

The situation is more subtle than this.

QEMU classifies block drivers into two sets - read-write and read-only, but this applies to the system emulator only. The non-emulator tools always allow read-write.

The intent behind QEMU's approach was that qemu-system-x86_64 should only allow write access with known good quality drivers (ie have high performance and not likely to corrupt data). The other formats are allowed read-only with qemu-system-x86_64 as a way to consume data from other hypervisors.

qemu-img was allowed full read-write support to allow bi-directional data liberation to/from arbitrary disk formats.

In RHEL-8 today we have this in qemu-kvm.spec

%global block_drivers_list qcow2,raw,file,host_device,nbd,iscsi,rbd,blkdebug,luks,null-co,nvme,copy-on-read,throttle
%if 0%{have_gluster}
    %global block_drivers_list %{block_drivers_list},gluster
%endif

  --block-drv-rw-whitelist=%{block_drivers_list}
  --block-drv-ro-whitelist=vmdk,vhdx,vpc,https,ssh


IOW, VMDK is already blocked from read-write usage with qemu-system-x86-64, but is allowed with qemu-img.

The latter is the scenario where Bug #1955608 reported the perf limitations. 

Note, the read-write usage is also permitted in other tools like  qemu-io and qemu-nbd  - I think that qemu-nbd probably ought to honour the restricted read-write driver list.

I guess we could introduce a configure option that makes tools respect the same list as the emulator.

This would affect more than just vmdk: The drivers in the list Daniel mentioned above (vmdk, vhdx, vpc, https, ssh) would all become read-only in tools. Additionally, all drivers that are compiled in, but not in either list, would be completely disabled (blklogwrites, blkverify, compress, ftp, ftps, host_cdrom, http, iser, null-aio, preallocate, quorum).

I think this is fine. None of them look like something you could need in qemu-img or other tools specifically when you don't need them in VMs.

Virt-v2v uses "https" and "ssh", but only read-only.

Virt-v2v also uses "null-co" for writes (is this related to null-aio?).

In theory we can use "http" although probably no actual VMware
server only supports this and not "https".

Also virt-v2v is planning to use "compress" for qcow2 compression,
assuming this command is correct:
qemu-nbd --image-opts driver=compress,file.driver=qcow2,file.file.driver=file,file.file.filename=new.qcow2

"preallocate" looks interesting too.  Could it solve this bug?
https://bugzilla.redhat.com/show_bug.cgi?id=1845518

(In reply to Richard W.M. Jones from comment #6)
> Virt-v2v also uses "null-co" for writes (is this related to null-aio?).

It provides the same functionality, but using different code paths. null-co is whitelisted, so this wouldn't be a problem.

> In theory we can use "http" although probably no actual VMware
> server only supports this and not "https".
> 
> Also virt-v2v is planning to use "compress" for qcow2 compression,
> assuming this command is correct:
> qemu-nbd --image-opts
> driver=compress,file.driver=qcow2,file.file.driver=file,file.file.
> filename=new.qcow2

I think there are some restrictions for compressed writes like that you can't write twice to the same cluster with it, but if you're starting with an empty image and writing sequentially to it, this looks good to me. (Though I don't think I've ever tried out the 'compress' filter myself.)

If you want to use this, please open a bug so that we can explicitly enable the driver. Same for 'http' if you think it could be used, though it may have been intentional to support only 'https'?

> "preallocate" looks interesting too.  Could it solve this bug?
> https://bugzilla.redhat.com/show_bug.cgi?id=1845518

Looks unrelated. This is the commit message and documentation for the 'preallocate' filter:

commit 33fa2222eb044147e75e5ec395e1fd53328bc9fb
Author: Vladimir Sementsov-Ogievskiy <vsementsov>
Date:   Wed Oct 21 17:58:46 2020 +0300

    block: introduce preallocate filter
    
    It's intended to be inserted between format and protocol nodes to
    preallocate additional space (expanding protocol file) on writes
    crossing EOF. It improves performance for file-systems with slow
    allocation.

##
# @BlockdevOptionsPreallocate:
#
# Filter driver intended to be inserted between format and protocol node
# and do preallocation in protocol node on write.
#
# @prealloc-align: on preallocation, align file length to this number,
#                  default 1048576 (1M)
#
# @prealloc-size: how much to preallocate, default 134217728 (128M)
#
# Since: 6.0
##

Here's the feature request about "compress":
https://bugzilla.redhat.com/show_bug.cgi?id=1980035

Looking back over my email, it seems we did deliberately
disable "http" because virt-v2v does not use it (only "https"),
so let's not touch that one.

QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.

Hi Kevin,

Tried to verify this bug as below, booting from and converting to an image with VMDK all failed with read-only prompt, but creating an image with VMDK works. Could you please help to check whether the results are as expected?

Plus, could you please help to check whether the test scenarios are enough? If not, what else should I test?

Thanks in advance.



Tested with:
qemu-kvm-6.0.0-10.el9
kernel-5.14.0-0.rc2.23.el9.x86_64


Steps and results:
1. Create an image with VMDK format. ---------------------------> Success.
# qemu-img create -f vmdk testtt.vmdk 2G
Formatting 'testtt.vmdk', fmt=vmdk size=2147483648 compat6=off hwversion=undefined
# echo $?
0

2. Boot up a guest from a VMDK image. -------------------------------> Fail with read-only.
qemu-kvm: -blockdev driver=vmdk,node-name=my,file=my_file: Driver 'vmdk' can only be used for read-only devices

3. Convert an image to a VMDK image. -----------------------------------> Fail with read-only.
# qemu-img convert -f qcow2 -O vmdk test.qcow2 tgt.vmdk -p
qemu-img: Could not open 'tgt.vmdk': Driver 'vmdk' can only be used for read-only devices

4. Convert a VMDK image to another image with other format. --------------------------------------> Success.
# qemu-img convert -f vmdk -O raw test.vmdk tgt.img -p
    (100.00/100%)
# echo $?
0

Confirmed with Kevin via IRC, the test scenarios are enough to set this bug as verified. So I will clear the needinfo. Thanks Kevin.