[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats
From: |
Max Reitz |
Subject: |
Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats |
Date: |
Wed, 30 Aug 2017 13:18:31 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
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
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, (continued)
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Fam Zheng, 2017/08/27
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, John Snow, 2017/08/28
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Yaniv Lavi (Dary), 2017/08/29
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Max Reitz, 2017/08/30
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Yaniv Lavi (Dary), 2017/08/30
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, John Snow, 2017/08/30
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Yaniv Lavi (Dary), 2017/08/31
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, John Snow, 2017/08/28
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Eric Blake, 2017/08/29
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, John Snow, 2017/08/29
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats,
Max Reitz <=
- Re: [Qemu-block] [Qemu-devel] Persistent bitmaps for non-qcow2 formats, Max Reitz, 2017/08/30
Re: [Qemu-block] Persistent bitmaps for non-qcow2 formats, Max Reitz, 2017/08/23
Re: [Qemu-block] Persistent bitmaps for non-qcow2 formats, Stefan Hajnoczi, 2017/08/30