[RFC PATCH 0/7] To make <transient/> disk sharable

[Peter Krempa]

On Mon, Jan 25, 2021 at 11:28:00 +0100, Peter Krempa wrote:
> On Mon, Jan 25, 2021 at 10:13:51 +0000, Daniel Berrange wrote:
> > On Mon, Jan 25, 2021 at 11:11:43AM +0100, Peter Krempa wrote:
> > > On Mon, Jan 25, 2021 at 10:04:41 +0000, Daniel Berrange wrote:
> 
> [...]
> 
> > > Unfortunately that's after the frontend is initialized (and thus
> > > remembers the readonly state) and after the storage is already open
> > > (thus it already asserted-or wanted to assert the write lock).
> > > 
> > > 'blockdev-create' is used to prevent another invocation of qemu-img
> > 
> > Wouldn't it make life simpler to just use qemu-img and avoid these
> > problems in the first place ? 
> 
> The use of 'qemu-img' in the qemu driver code is limited to inactive
> snapshots and I'd really like us to keep it that way.
> 
> I'm more willing to declare that sharing of the original image with a
> <transient/> disk is unsupported rather than cave in using qemu-img.

To be more specific, qemu-img uses a really crusty old commadline.
Trying to adapt any blockdev code to it (such as encrypted qcow2 and
others) isn't something I see a point in doing and maintaining an
interlocking matrix of supported things.

Similarly, the idea for supporting offline-blockjobs was always to use
either qemu -m none or nowadays qemu-storage-daemon, rather than trying
to probe and adapt to the quirks of qemu-img.