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.
