[Qemu-devel] [RFC] qemu-img: add option -d in convert

[Qemu-devel] [RFC] qemu-img: add option -d in convert

[Wenchao Xia]

Hi,
  This is a draft design which aimed for internal snapshot convert,
hope to get your comments:

  Internal snapshot is not as easy as external snapshot, to query and
convert. This patch will improve convertion side, which helps internal
/ external snapshot mixed case. With it user can treat internal
snapshot as lineraity relationship, use it like external ones with
tool qemu-img.


An detailed example, If there is a chain as following:

imageA(sn0)->imageB(sn0,sn1)->imageC(sn0)

The real relationship in it could be:
-->imageA.qcow2---->imageB.qcow2--------->imageC.qcow2
|->imageA(sn0)   |->imageB(sn0)        |->imageC(sn0)
                 |->imageB(sn1)

To export it, two steps:
1. duplicate them to get an exactly same tree by:
qemu-img convert imageA.qcow2 -O export/imageA.qcow2 -f qcow2
qemu-img convert imageA.qcow2 -s sn0 -O export/imageA_sn0.qcow2
qemu-img convert imageB.qcow2 -O export/imageB.qcow2 -f qcow2 -o
backing_file=export/imageA.qcow2
qemu-img convert imageB.qcow2 -s sn0 -O export/imageB.qcow2 -f qcow2 -o
backing_file=export/imageB.qcow2
...

result at ./export:
-->imageA.qcow2-------->imageB.qcow2--------->imageC.qcow2
|->imageA_sn0.qcow2  |->imageB_sn0.qcow2   |->imageC_sn0.qcow2
                     |->imageB_sn1.qcow2

2. change the relationship to linearity to save space(or by 3rd party
diff tool):
qemu-img create imageA_l.qcow2 -f qcow2 -p backing_file=imageA_qcow2
qemu-img rebase imageA_l.qcow2 -b imageA_sn0.qcow2
qemu-img rebase -u imageB.qcow2 -b imageA_l.qcow2
discard imageA.qcow2
........

result at ./export:
imageA_sn0.qcow2-->imageA_l.qcow2-->imageB_sn0.qcow2-->imageB_sn1_l.qcow2-
->imageB_l.qcow2-->imageC_sn0.qcow2-->imageC_l.qcow2


This is a bit complexity, they can be merged into one step, to save
disk I/O and make procedure simple, add a parameter:
[-d [base_image=IMAGE,]snapshot=SNAPSHOT]

qemu-img convert imageA.qcow2 -s sn0 -O export/imageA_sn0.qcow2 -f qcow2
qemu-img convert imageA.qcow2 -d snapshot=sn0 -O export/imageA.qcow2 -f
qcow2 -o backing_file=export/imageA_sn0.qcow2
...........

result at ./export:
imageA_sn0.qcow2-->imageA.qcow2-->imageB_sn0.qcow2-->imageB_sn1.qcow2-
->imageB.qcow2-->imageC_sn0.qcow2-->imageC.qcow2

parameter base_image allow diff operation taken across image in the
backing chain.

Note:
  1 snapshot query can be added in qemu-nbd easily later.
  2 This is actually a work around by qemu-img and qemu-nbd. A better
way is to provide user snapshot_read() and snapshot_allocated()
interface, typically a library. But that need some adjust in block
level, especially thread, coroutine, and emulator cut off, so delay
that.

-- 
Best Regards

Wenchao Xia

Re: [Qemu-devel] [RFC] qemu-img: add option -d in convert

[Stefan Hajnoczi]

On Thu, Jun 20, 2013 at 04:59:17PM +0800, Wenchao Xia wrote:

If I understand correctly, you have a backing chain with internal
snapshots:

> imageA(sn0)->imageB(sn0,sn1)->imageC(sn0)

And you want to convert this to a chain of external snapshots:

> imageA_sn0.qcow2-->imageA.qcow2-->imageB_sn0.qcow2-->imageB_sn1.qcow2-
> ->imageB.qcow2-->imageC_sn0.qcow2-->imageC.qcow2

You also want each image file to contain only data that is not in the
parent.  So imageA.qcow2 would not contain identical clusters from
imageA_sn0.qcow2.

The most efficient way of doing this is by looking into the L1/L2 tables
of the imageA(sn0) and imageA so that you know which clusters are
different.

This is a weird operation.  It also has a dual, converting the external
snapshot chain into a chain of image files with internal snapshots -
again sharing clusters instead of duplicating them.

It's possible to implement this but I'm a little surprised that anyone
would want to do this.  And I wonder if management tools can cope with
this mix of internal and external snapshots :).

Stefan

Re: [Qemu-devel] [RFC] qemu-img: add option -d in convert

[Wenchao Xia]

于 2013-6-25 17:13, Stefan Hajnoczi 写道:
> On Thu, Jun 20, 2013 at 04:59:17PM +0800, Wenchao Xia wrote:
>
> If I understand correctly, you have a backing chain with internal
> snapshots:
>
>> imageA(sn0)->imageB(sn0,sn1)->imageC(sn0)
>
> And you want to convert this to a chain of external snapshots:
>
   What it looks like is convert into external snapshots, actually
requirement is get delta data from internal snapshot, external snapshots
have delta data by nature so it is a way to orginize it. This patch
will help get that delta data.

>> imageA_sn0.qcow2-->imageA.qcow2-->imageB_sn0.qcow2-->imageB_sn1.qcow2-
>> ->imageB.qcow2-->imageC_sn0.qcow2-->imageC.qcow2
>
> You also want each image file to contain only data that is not in the
> parent.  So imageA.qcow2 would not contain identical clusters from
> imageA_sn0.qcow2.
>
   yes, it is the purpose, delta data.

> The most efficient way of doing this is by looking into the L1/L2 tables
> of the imageA(sn0) and imageA so that you know which clusters are
> different.
>
   There would be two steps I think: 1st is simply compare the cluster
to get delta, 2nd is improve it: when 2 snapshots is in one qcow2,
introduce a function to looking into L1/L2.

> This is a weird operation.  It also has a dual, converting the external
> snapshot chain into a chain of image files with internal snapshots -
> again sharing clusters instead of duplicating them.
>
   Indeed, but converting external chain into internal snapshots, is not
that useful as its revert, since in most case qemu-img can directly
convert external chain back to restore a snapshot. It can be added if
some case appear.

> It's possible to implement this but I'm a little surprised that anyone
> would want to do this.  And I wonder if management tools can cope with
> this mix of internal and external snapshots :).
>
   I think it is useful: internal snapshot have advantage about
performance, but disadvantage for delta data retrieving. This patch
will help it. When it is online, the user, for example, libvirt,
can retrieve internal/external ones very similar, it simply calls
qemu-img to get the delta for both case.

> Stefan
>


-- 
Best Regards

Wenchao Xia

Re: [Qemu-devel] [RFC] qemu-img: add option -d in convert

[Stefan Hajnoczi]

On Tue, Jun 25, 2013 at 07:14:19PM +0800, Wenchao Xia wrote:
> 于 2013-6-25 17:13, Stefan Hajnoczi 写道:
> >On Thu, Jun 20, 2013 at 04:59:17PM +0800, Wenchao Xia wrote:
> >
> >If I understand correctly, you have a backing chain with internal
> >snapshots:
> >
> >>imageA(sn0)->imageB(sn0,sn1)->imageC(sn0)
> >
> >And you want to convert this to a chain of external snapshots:
> >
>   What it looks like is convert into external snapshots, actually
> requirement is get delta data from internal snapshot, external snapshots
> have delta data by nature so it is a way to orginize it. This patch
> will help get that delta data.

Copying all the data out into external files in order to get
is_allocated information seems very inefficient.

We've discussed dirty block tracking APIs on the list several times.
This seems related.

Maybe it's time to tackle this properly for both external and internal
snapshots.

The reason why a dirty block tracking API is also helpful is that not
all tools want to learn how to open different image file formats.  (Even
with libqblock.)

The drity block tracking API gives them information which they can use
together with a single interface like NBD or a libvirt block pread-style
interface to read out dirty blocks.

BTW we already have qemu-io -c map which prints out allocation
information for an image file.  If that command is extended to support
-s then you can get your info easily.

Stefan

Re: [Qemu-devel] [RFC] qemu-img: add option -d in convert

[Wenchao Xia]

于 2013-6-27 17:01, Stefan Hajnoczi 写道:
> On Tue, Jun 25, 2013 at 07:14:19PM +0800, Wenchao Xia wrote:
>> 于 2013-6-25 17:13, Stefan Hajnoczi 写道:
>>> On Thu, Jun 20, 2013 at 04:59:17PM +0800, Wenchao Xia wrote:
>>>
>>> If I understand correctly, you have a backing chain with internal
>>> snapshots:
>>>
>>>> imageA(sn0)->imageB(sn0,sn1)->imageC(sn0)
>>>
>>> And you want to convert this to a chain of external snapshots:
>>>
>>    What it looks like is convert into external snapshots, actually
>> requirement is get delta data from internal snapshot, external snapshots
>> have delta data by nature so it is a way to orginize it. This patch
>> will help get that delta data.
>
> Copying all the data out into external files in order to get
> is_allocated information seems very inefficient.
>
> We've discussed dirty block tracking APIs on the list several times.
> This seems related.
>
> Maybe it's time to tackle this properly for both external and internal
> snapshots.
>
> The reason why a dirty block tracking API is also helpful is that not
> all tools want to learn how to open different image file formats.  (Even
> with libqblock.)
>
> The drity block tracking API gives them information which they can use
> together with a single interface like NBD or a libvirt block pread-style
> interface to read out dirty blocks.
   Nice to have the dirty block tracking API. As the discuss before, it
may be implemented as best effort which kept in memory, and I think it
is right because dirty map already exist in some block format, do that
in block seems a duplicated implemention.
   If that API is online, the approach in this patch, would be the
backed way to get delta data, when qemu is not shutdown gracefully.
What I can think is later additional parameter: -dirty_out file,
which will rebuild the dirty info with -d file_compare.
   For internal snapshot, still I need an easy way to get delta data
of historic ones which may have no dirty block tracking info.


>
> BTW we already have qemu-io -c map which prints out allocation
> information for an image file.  If that command is extended to support
> -s then you can get your info easily.
   Do you mean use it like:
   1 call qemu-io file -c map -s sn0
   2 call qemu-io file -c map -s sn1
   3 for (offset = 0; offset < len; offset +=512) {
         if (allocated on sn0) {
              call qemu-io file read -s sn0, into buf0
         }
         if (allocated on sn1) {
              call qemu-io file read -s sn1, into buf1
         }
         if strcmp(buf0, buf1) {
              write down the delta
         }
     }
?
   I think it is workable and flex, the bottle neck is the string
parsing of qemu-io. For delta data info retrieving purpose, qemu-img
approach would faster.

>
> Stefan
>


-- 
Best Regards

Wenchao Xia

Re: [Qemu-devel] [RFC] qemu-img: add option -d in convert

[Wenchao Xia]

于 2013-6-27 17:01, Stefan Hajnoczi 写道:
> On Tue, Jun 25, 2013 at 07:14:19PM +0800, Wenchao Xia wrote:
>> 于 2013-6-25 17:13, Stefan Hajnoczi 写道:
>>> On Thu, Jun 20, 2013 at 04:59:17PM +0800, Wenchao Xia wrote:
>>>
>>> If I understand correctly, you have a backing chain with internal
>>> snapshots:
>>>
>>>> imageA(sn0)->imageB(sn0,sn1)->imageC(sn0)
>>>
>>> And you want to convert this to a chain of external snapshots:
>>>
>>    What it looks like is convert into external snapshots, actually
>> requirement is get delta data from internal snapshot, external snapshots
>> have delta data by nature so it is a way to orginize it. This patch
>> will help get that delta data.
>
> Copying all the data out into external files in order to get
> is_allocated information seems very inefficient.
>
   Forget to say, my purpose is not get is_allocated info, but
get the different data between two snapshots or images. Now qemu-img
can do it in-directly as the example shows, the -d option will make it
simpler and faster.

for example imageA(sn0, sn1, sn2), it will help to get different data
between sn0 and sn2.

   An alternative way is let qemu-nbd export sn0 and sn2, then user
diff the data itself, but we lost the chance to use L1/L2 table
, allocated info, to accelerate it.

> We've discussed dirty block tracking APIs on the list several times.
> This seems related.
>
> Maybe it's time to tackle this properly for both external and internal
> snapshots.
>
> The reason why a dirty block tracking API is also helpful is that not
> all tools want to learn how to open different image file formats.  (Even
> with libqblock.)
>
> The drity block tracking API gives them information which they can use
> together with a single interface like NBD or a libvirt block pread-style
> interface to read out dirty blocks.
>
> BTW we already have qemu-io -c map which prints out allocation
> information for an image file.  If that command is extended to support
> -s then you can get your info easily.
>
> Stefan
>


-- 
Best Regards

Wenchao Xia

Re: [Qemu-devel] [RFC] qemu-img: add option -d in convert

[Stefan Hajnoczi]

On Thu, Jun 27, 2013 at 08:30:04PM +0800, Wenchao Xia wrote:
> 于 2013-6-27 17:01, Stefan Hajnoczi 写道:
> >On Tue, Jun 25, 2013 at 07:14:19PM +0800, Wenchao Xia wrote:
> >>于 2013-6-25 17:13, Stefan Hajnoczi 写道:
> >>>On Thu, Jun 20, 2013 at 04:59:17PM +0800, Wenchao Xia wrote:
> >BTW we already have qemu-io -c map which prints out allocation
> >information for an image file.  If that command is extended to support
> >-s then you can get your info easily.
>   Do you mean use it like:
>   1 call qemu-io file -c map -s sn0
>   2 call qemu-io file -c map -s sn1
>   3 for (offset = 0; offset < len; offset +=512) {
>         if (allocated on sn0) {
>              call qemu-io file read -s sn0, into buf0
>         }
>         if (allocated on sn1) {
>              call qemu-io file read -s sn1, into buf1
>         }
>         if strcmp(buf0, buf1) {
>              write down the delta
>         }
>     }
> ?
>   I think it is workable and flex, the bottle neck is the string
> parsing of qemu-io. For delta data info retrieving purpose, qemu-img
> approach would faster.

It's also possible to put Step 3 into qemu-img so that this feature is
fast and easy to use with a single command.

Stefan