[Qemu-devel] Supporting unsafe create when backing file is not accessible

[Ala Hino]

Hi,

We encountered a performance issue when creating a volume for a running VM
and we'd like to share the info with you. The root cause of the issue is in
our code but we found a workaround that relies on qemu-img create
undocumented behavior.

During our tests, we found that in order to create a volume with a backing
file, the baking file has to be valid and accessible. This requires us to
activate the entire chain before creating the volume, and deactivate the
chain after the operation completes. Activating and deactivating the chain
are expensive operations that we prefer to avoid when possible. Below is
the command we use to create volumes:

qemu-img create -f qcow2 -o compat=1.1 -b
8a28cda2-548d-47da-bbba-faa81284f6ba -F raw
/rhev/data-center/e6b272af-84cb-43fc-ae5b-7fe18bc469a2/f47c980a-fd76-44a9-8b78-00d3ab2ffd2f/images/2ff0a3c0-f145-4f83-b668-fc0c39ba191f/d3b69657-892f-499c-9ac3-9c443ead7d9b
1073741824

We also found that when providing the size and the backing format for qemu,
qemu doesn't open the backing chain, and in this case we don't have to
activate/deactivate the entire chain - exactly the behavior we wish to have.
We we'd like to get your confirmation of the above behavior as it isn't
documented, and whether it can be documented.

In addition, we are aware of https://bugzilla.redhat.com/1213786, where a
-u (unsafe) option is planned to be added (see comment #4 in the BZ). Can
you please confirm that once that support is released, it won't break
existing, i.e. code that provides size and backing format assuming that
"unsafe" create is supported?

Thanks,
Ala