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.