Re: [RFC PATCH 0/7] To make <transient/> disk sharable
On Mon, Jan 25, 2021 at 09:33:31 +0000, Daniel Berrange wrote:
On Sat, Jan 23, 2021 at 11:54:51AM +0100, Peter Krempa wrote:
> On Fri, Jan 22, 2021 at 20:10:59 -0500, Masayoshi Mizuma wrote:
> > From: Masayoshi Mizuma <m.mizuma(a)jp.fujitsu.com>
[...]
> Please note that this is a high level review. I've spotted
some coding
> style inconsistencies and such, but since this will need significant
> rework I'll not point them out.
>
> Also don't forget to add test cases, where it will be visible that the
> disk (neither frontend nor backend) is added on the commandline.
>
> Also it should be fairly trivial to support it for SCSI disks since they
> support hotplug too.
Is there a reason we can't use the existing <readonly/> element as a way
to make the underlying base image be treated as read only and thus become
sharable ?
The problem is that the qemu device frontend code infers the readonly
state from the backend image specification when it's instantiated.
Thus if you start qemu with the topmost layer marked as read-only so
that the write lock doesn't get asserted, this fact gets stored in the
frontend. If you then later insert a writable layer into the chain on
top of it, the frontend stays read-only.
IDE/SATA disks are outhright refused to be read-only by qemu, virtio
disks remember that they are read-only and keep it into guest execution
and SCSI disks caused an abort() (which was recently fixed in qemu
upstream.)
Thus the only two options are:
1) hotplug the frontend after we do the shenanigans with the image
2) implement explicit control of the read-only state of the frontend in
qemu in the first place, adapt to it in libvirt and then keep using
the current approach in libvirt