Re: [Qemu-devel] [PATCH 0/2] qemu block changes: keep backing file format v2

[Uri Lublin <uril@redhat.com>]

Anthony Liguori wrote:
> Uri Lublin wrote:
>> Jamie Lokier wrote:
>>> Uri Lublin wrote:
>>>> I call "hidden image format" to the following format of a backing 
>>>> file name:
>>>> "name\0format". Although it can be considered a hack, that's an easy
>>>> way to support old images with new qemu as well as old qemu with new 
>>>> images
>>>> (in which case probing would be done), without changing the qcow2 
>>>> header.
>>> ...
>>>> Changes from v1: use "name\0format" instead of "fmt:FMT:name"
>>>
>>> Do you think there will be any other information added in future,
>>> while wanting to remain compatible with old qemus (i.e. without
>>> changing the qcow2 header)?
>>>
>>> If so, "name\0format=FMT", and stop at the second \0 if there is one,
>>> something like that?
>>>
>>> -- Jamie
>>
>> I think you'd always want to keep the format of your backing file, so 
>> as long as
>> you keep the order of options fixed, it's safe (meaning we can add 
>> more options following the format, and there is no need to parse it).
>>
>> If we are thinking about ways to extend the simple "name\0options" 
>> format,
> 
> How about just extending the qcow2 header instead of playing ugly games 
> with the backing_file field?
> 

Would that be considered qcow3 ?

Shahar's extensions are following in the qcow2 header (without breaking existing 
images). I forgot to mention they are only implemented for qcow2 images.

Currently backing files are being opened in block.c:bdrv_open2(). If we want to 
do something specific to qcow2 (with regards to the backing file format), we'll 
need to leave bs->backing_file empty and open the backing file from 
block-qcow2.c:qcow_open(). Or we can add a backing_format field to struct 
BlockDriverState.

Regards,
     Uri.

>> Shahar Frank wrote a better, more extensible implementation, which 
>> saves image options as extensions following the qcow2-header. The 
>> options are saved in a binary format similar to the header. Each 
>> option has a little header of its own which includes magic(==type) and 
>> len.
>>
>> We (Shahar) also implemented a zero-cluster (aka zero-dedup) and would 
>> like,
>> in the future, to keep the offset of that cluster.
>>
>> If such an approach is acceptable, I can work on a patch implementing 
>> it (rebase and improve a bit Shahar's implementation).
>>
>> Thanks,
>>     Uri.