[Qemu-devel] Can the backing file of qcow2 points to a snapshot of base file?

[Qemu-devel] Can the backing file of qcow2 points to a snapshot of base file?

[vt]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]


Hi.

If a base qcow2 image snapshot chain like this:

base.qcow2: [A] -> [B] -> [C]

[C] is the current image where guest read/write to,usually we create a new image base on the base.qcow2 like this

qemu-img create -f qcow2 -o backing_file=/path/base.qcow2 new.qcow2

so the data of new.qcow2 is from [C] of base.qcow2, assuming the new.qcow2 has not been write to since created.

What I want is that the data of new.qcow2 is from [B] of base.qcow2, like this:

qemu-img create -f qcow2 -o backing_file=/path/base.qcow2,backing_snapshot=B  new.qcow2

Can the qemu support it now?

Thanks



vt

[-- Attachment #2: Type: text/html, Size: 1603 bytes --]

Re: [Qemu-devel] Can the backing file of qcow2 points to a snapshot of base file?

[Max Reitz]

On 06.07.2015 10:20, vt wrote:
> Hi.
> If a base qcow2 image snapshot chain like this:
> base.qcow2: [A] -> [B] -> [C]
> [C] is the current image where guest read/write to,usually we create a
> new image base on the base.qcow2 like this
> qemu-img create -f qcow2 -o backing_file=/path/base.qcow2 new.qcow2
> so the data of new.qcow2 is from [C] of base.qcow2, assuming the
> new.qcow2 has not been write to since created.
> What I want is that the data of new.qcow2 is from [B] of base.qcow2,
> like this:
> qemu-img create -f qcow2 -o
> backing_file=/path/base.qcow2,backing_snapshot=B  new.qcow2
> Can the qemu support it now?
> Thanks
> ------------------------------------------------------------------------
> vt

Hi vt,

I don't think this is possible. For this to work, the snapshot would 
have to be loaded temporarily, but the only place I can see in the qemu 
code base where this is done is inside qemu-img and qemu-nbd, so qemu 
itself appearently does not support this.

What you can do is export the snapshot via qemu-nbd (-l) and then use 
that NBD server as a backing file with qemu. This is not very nice, but 
I don't suppose there are many people eager to implement the 
functionality you'd like to have (although I don't think it would be too 
difficult, frankly…).

Max

[Qemu-devel] 回复: Re: Can the backing file of qcow2 points to a snapshot of base file?

[vt]

[-- Attachment #1: Type: text/plain, Size: 1800 bytes --]

On 2015/7/6 20:09, Max Reitz wrote:
> On 06.07.2015 10:20, vt wrote:
>> Hi.
>> If a base qcow2 image snapshot chain like this:
>> base.qcow2: [A] -> [B] -> [C]
>> [C] is the current image where guest read/write to,usually we create a
>> new image base on the base.qcow2 like this
>> qemu-img create -f qcow2 -o backing_file=/path/base.qcow2 new.qcow2
>> so the data of new.qcow2 is from [C] of base.qcow2, assuming the
>> new.qcow2 has not been write to since created.
>> What I want is that the data of new.qcow2 is from [B] of base.qcow2,
>> like this:
>> qemu-img create -f qcow2 -o
>> backing_file=/path/base.qcow2,backing_snapshot=B  new.qcow2
>> Can the qemu support it now?
>> Thanks
>> ------------------------------------------------------------------------
>> vt 
>
> Hi vt,
>
> I don't think this is possible. For this to work, the snapshot would have to be loaded temporarily, but the only place I can see in the qemu code base where this is done is inside qemu-img and qemu-nbd, so qemu itself appearently does not support this.
>
> What you can do is export the snapshot via qemu-nbd (-l) and then use that NBD server as a backing file with qemu. This is not very nice, but I don't suppose there are many people eager to implement the functionality you'd like to have (although I don't think it would be too difficult, frankly…).
>
> Max

Thanks, Max!

It seems that I have to implement the functionality by myself...

Here is my plan:

1. Pass the snapshot name(id) by -drive
2. Get the snapshot name(id) in the bdrv_open_backing_file() -> qcow2_open() and load the snapshot header
3. Load BDRVQcowState.l1_table with the snapshot's l1 table

Does it look ok?

Thanks
------------------------------------------------------------------------
vt

[-- Attachment #2: Type: text/html, Size: 4319 bytes --]