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: Wed, 23 Aug 2017 13:44:23 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1


On 08/23/2017 01:31 PM, Max Reitz wrote:
> 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.
> 

Yeah, it's not necessarily my first pick, but it might be the least bad.
If you have any suggestions or alternatives for a way to accomplish the
same in a way that does not leave any, even faint, bad taste in your
mouth you are more than welcome to suggest it.

> 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
> 

Ah, right. Well... I'll just have to have something fun for him to look at.



reply via email to

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