To start multiple KVM guests from one qcow2 image with transient disk option

[Masayoshi Mizuma]

On Sat, Dec 12, 2020 at 11:57:15AM +0100, Peter Krempa wrote:
> On Fri, Dec 11, 2020 at 20:58:48 -0500, Masayoshi Mizuma wrote:
> > Hello,
> > 
> > I would like to start multiple KVM guests from one qcow2 image, and
> > discard the changes which the KVM guests done.
> > 
> > transient disk option is useful for discarding the changes, however,
> > we cannot start multiple KVM guest from one qcow2 image because the
> > image is write-locked by the first guest to be started.
> > 
> > I suppose the disk which transient option is enabled don't need to
> > get the write lock because any changes go to the overlay image, and
> > the overlay image is removed when the guest shutdown.
> > 
> > qemu has 'locking' option and the write lock is disabled when locking=off.
> > To implement that, I have two ideas. I would appreciate it if you could
> > give me the ideas which way is better (or another way).
> 
> There are two aspects of this.
> 
> 1) Controlling the locking property of qemu may be worth in many cases,
> so by itself this would be a worthwhile patchset to add control of
> qemu locking for a per-backing store basis.
> 
> 2) Disabling locking to achieve this is wrong though. The qemu image
> locking infrastructure is justified and prevents many problems which
> users might get into by wrong configuration.
> 
> For <transient/> disks, we should rather instantiate the top level
> format node as 'readonly' and then put a read-write overlay on top of
> it. This still prevents from using the file which became a backing file
> in read-write mode in another VM.

Thank you for the idea!
I just tried to change the original image to read-only (changed the "read-only":false
to "read-only":true) simply, then created a read-write overlay.
qemu stopped with following assertion:

  qemu-system-x86_64: ../block/io.c:1874: bdrv_co_write_req_prepare: Assertion `child->perm & BLK_PERM_WRITE' failed.

It looks like the qemu hit the assertion because the permission of the overlay image
is same as the original image.
Probably I'm missing something... I'll dive into that...

> 
> You are welcome to propose the locking control as a proper patchset
> (with proper splitting of patches) but it can't be described as a way to
> share the backing image of <transient/> disks since that needs a
> systemic fix.

Thanks. I understand the locking option is different topic from sharing
disks with <transient/> option.

Thanks!
Masa