qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Snow
Subject: Re: [Qemu-devel] Persistent bitmaps for non-qcow2 formats
Date: Tue, 29 Aug 2017 17:02:20 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1


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.

--js



reply via email to

[Prev in Thread] Current Thread [Next in Thread]