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

[Uri Lublin]

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.