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

[Max Reitz]

On 2017-08-22 21:07, John Snow wrote:

[...]

> (3) Add either a new flag that turns qcow2's backing file into a full
> R/W backing file, or add a new extension to qcow2 entirely (bypassing
> the traditional backing file mechanism to avoid confusion for older
> tooling) that adds a new read-write backing file field.
> 
> This RW backing file field will be used for all reads AND writes; the
> qcow2 in question becomes a metadata container on top of the BDS chain.
> We can re-use Vladimir's bitmap persistence extension to save bitmaps in
> a qcow2 shell.
> 
> The qcow2 becomes effectively a metadata cache for a new (essentially)
> filter node that handles features such as bitmaps. This could also be
> used to provide allocation map data for RAW files and other goodies down
> the road.
> 
> Hopefully this achieves our desire to not create new formats AND our
> desire to concentrate features (and debugging, testing, etc) into qcow2,
> while allowing users to "have bitmaps with raw files."
> 
> Of course, in this scenario, users now have two files: a qcow2 wrapper
> and the actual raw file in question; but regardless of how we were going
> to solve this, a raw file necessitates an external file of some sort,
> else we give up the idea that it was a raw file.
> 
> 
> Sound good?

While I don't quite like the idea of R/W backing files, I guess "don't
quite like" is still rather good.

I like how this idea would allow us to use the existing code without
putting just arbitrary binary data into the qcow2 file; the data still
relates to the virtual disk represented by the qcow2 image.

So design-wise, I don't think I have any complaints.

As for Kevin, he's on PTO, though. ;-)

Max

signature.asc
Description: OpenPGP digital signature