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

[Eric Blake]

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.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature