Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats

[Max Reitz <mreitz@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4039 bytes --]

On 2017-08-29 23:02, John Snow wrote:
> 
> 
> On 08/29/2017 10:30 AM, Eric Blake wrote:
>> On 08/28/2017 08:18 PM, John Snow wrote:
>>>>> We'd have to develop a new syntax for specifying these resources that
>>>>> can be stored in a qcow2 file,
>>>>
>>>> It's called the json-pseudo-protocol and was developed exactly for this.
>>>>
>>>
>>> That's what I was hinting at for "or otherwise co-opt an existing
>>> syntax" but I was unaware that it was intended for "exactly" this.
>>>
>>> Do we actually use it in any on-disk format, currently? qcow2 only lets
>>> you specify simple filenames in the qcow2 metadata, right?
>>
>> You can specify json-pseudo backing names both on the command line AND
>> embedded in the qcow2 file itself (within the length limits imposed by
>> the qcow2 header size).  Yes, this means it is already possible to
>> create qcow2 files that can only be opened by qemu (or else teaching
>> your alternative program how to parse qemu's json-pseudo-protocol).
>>
>>>
>>>>>                                or otherwise co-opt an existing syntax
>>>>> in-use by QEMU. This syntax would likely be useful only to QEMU, which
>>>>> would steer the qcow2 format in a direction not too useful by other
>>>>> emulators, and qcow2 is an open format, so we may want to avoid this.
>>>>
>>>> Storing a file name in the backing link field that cannot be interpreted
>>>> by other programs is in my opinion still very much better than not
>>>> storing any information whatsoever, because in the former case other
>>>> programs can at least say "sorry, I have no idea what this means" (or
>>>> maybe they can indeed interpret it, who knows), whereas in the latter
>>>> they may not even know that the qcow2 image is incomplete.
>>>>
>>>
>>> I don't disagree personally, but I seem to recall that Kevin was adamant
>>> that the qcow2 bitmap extension should remain useful and semantically
>>> meaningful to third parties, so I try to keep that in mind. Maybe I
>>> should let him chime in instead of try to "concern troll" my own
>>> suggestions into the ground.
>>
>> We already have that situation today, but you are right to worry about
>> whether making it even more prevalent is something we can try to minimize.
>>
> 
> Proposal distillate:
> 
> (1) Specify relationship on CLI, QCOW becomes a bitmap-child of any
> arbitrary node.
> 
> Pros: Easy to implement
>       Adds bitmap support to literally everything
> Cons: Bitmap has no semantic link to data it describes
>       Relationship must be re-specified every launch
>       Max and Kevin are firmly NACK
> 
> (2) Raw file becomes a R/W backing file of the QCOW2, implemented as
> either a bitmap-child or a more traditional backing file that can
> additionally service writes
> 
> Pros: Easy to understand
>       relationship between files exists outside of the QEMU process
>       Adds bitmap support to just about everything that can be expressed
> via JSON
> Cons: All but necessitates QEMU-specific syntax in a qcow2 file
>       Depending on implementation, possibly messy in bdrv_open
>       Adding bitmaps to non-qcow2 files after open makes the launch CLI
> invalid for future launches (Not any different to snapshots.)
> 
> (3) Add a raw-like mapping mode to QCOW2 instead, skipping the whole affair
> 
> Pros: Adds a nice, performant hybrid mode to qcow2
>       Solves the problem of "bitmaps for raw" more or less
>       Avoids bdrv_open() complications
>       Avoids writing qemu-specific jargon in qcow2 files
> Cons: Doesn't actually add arbitrary bitmaps to any file format
>       Users are still gonna ask for bitmaps for other formats anyway
> 
> 
> 
> I think I like 2 or 3 -- or perhaps indeed two AND three. The qcow2-raw
> mode sounds like something we ought to have anyway. I'll try to start an
> RFC.

I think the only main thing that's missing for implementing (3) is a way
to mark allocated clusters to be fall-through-to-backing-file.

Max


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 512 bytes --]