Re: [RFC PATCH 0/7] To make <transient/> disk sharable
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.