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
