On Sat, Dec 19, 2020 at 11:30:39PM -0500, Masayoshi Mizuma wrote:
> On Thu, Dec 17, 2020 at 10:39:36AM +0100, Peter Krempa wrote:
> > On Mon, Dec 14, 2020 at 22:49:03 -0500, Masayoshi Mizuma wrote:
> > > 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...
> >
> > Could you please post the command line and the QMP commands? Maybe
> > something isn't configured right in libvirt. Alternatively qemu might
> > need modification.
>
> Sure, here is the qemu command line options and QMP commands:
>
> qemu command line options:
>
> qemu-system-x86_64 \
> -M q35,accel=kvm,usb=off,vmport=off,smm=on,dump-guest-core=off \
> -smp 4 \
> -m 4096 \
> -blockdev '{"driver":"file","filename":"/var/lib/libvirt/images/guest.qcow2","node-name":"storage1","auto-read-only":true,"discard":"unmap"}' \
> -blockdev '{"node-name":"format1","read-only":true,"driver":"qcow2","file":"storage1","backing":null}' \
> -device virtio-blk-pci,drive=format1,id=virtio-disk0,bootindex=1 \
> -nographic \
> -nodefaults \
> -no-user-config \
> -serial telnet::1235,server,nowait \
> -qmp tcp::1335,server,nowait \
> -S
>
> QMP commands:
> (Before running following QMP commands, I create '/var/lib/libvirt/images/guest.qcow2.TRANSIENT'
> by touch command)
>
> {"execute":"qmp_capabilities"}
> {"execute":"blockdev-add","arguments":{"driver":"file","filename":"/var/lib/libvirt/images/guest.qcow2.TRANSIENT","node-name":"storage2","auto-read-only":true,"discard":"unmap"}}
> {"execute":"blockdev-create","arguments":{"job-id":"create","options":{"driver":"qcow2","file":"storage2","size":10737418240,"cluster-size":65536,"backing-file":"/var/lib/libvirt/images/guest.qcow2","backing-fmt":"qcow2"}}}
> {"execute":"blockdev-add","arguments":{"node-name":"format2","read-only":false,"driver":"qcow2","file":"storage2","backing":null}}
> {"execute":"blockdev-snapshot","arguments":{"node":"format1","overlay":"format2"}}
> {"execute":"cont"}
>
> After "cont" command executed, qemu stops as following assertion:
>
> qemu-system-x86_64: ../block/io.c:1865: bdrv_co_write_req_prepare: Assertion `child->perm & BLK_PERM_WRITE' failed.
I think following qemu command line options and QMP commands work for sharing
the qcow2 disks. The following uses disk hotplug instead of snapshot overlay.
Does that make sense for libvirt...?
qemu command line options:
qemu-system-x86_64 \
-M q35,accel=kvm,usb=off,vmport=off,smm=on,dump-guest-core=off \
-smp 1 \
-m 4096 \
-blockdev '{"driver":"file","filename":"/home/mmizuma/debug/guest.qcow2","node-name":"storage1","auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"format1","read-only":true,"driver":"qcow2","file":"storage1","backing":null}' \
-nographic \
-nodefaults \
-no-user-config \
-serial telnet::10000,server,nowait \
-qmp tcp::10001,server,nowait \
-S \
-device pcie-root-port,id=pci.1
QMP commands:
{"execute":"qmp_capabilities"}
{"execute":"blockdev-add","arguments":{"driver":"file","filename":"/var/lib/libvirt/images/guest.TRANSIENT","node-name":"storage2","auto-read-only":true,"discard":"unmap"}}
{"execute":"blockdev-create","arguments":{"job-id":"create","options":{"driver":"qcow2","file":"storage2","size":4294967296,"cluster-size":65536,"backing-file":"/var/lib/libvirt/images/guest.TRANSIENT","backing-fmt":"qcow2"}}}
{"execute":"blockdev-add","arguments":{"node-name":"format2","read-only":false,"driver":"qcow2","file":"storage2"}}
{"execute":"device_add","arguments":{"driver":"virtio-blk-pci","drive":"format2","id":"transient-disk","bootindex":1,"bus":"pci.1","addr":0}}
{"execute":"cont"}
Thanks,
Masa
