[Qemu-devel] [RFC] Allow 'qemu-img convert' to preserve the backing file

[Qemu-devel] [RFC] Allow 'qemu-img convert' to preserve the backing file

[Marc Bevand]

Currently if qemu-img convert is used to convert for example a qcow1 image (with
a backing file) to a qcow2 image, the resulting image will have no backing file.

In order to preserve the backing file (to save disk space), qemu-img should
offer a command line option to enable the feature. For this it needs to be made
aware of BlockDrivers supporting backing files.

I need this feature and am going to implement it. If someone has any comment to
make, now is the time.

-marc

Re: [Qemu-devel] [RFC] Allow 'qemu-img convert' to preserve the backing file

[Ian Jackson]

Marc Bevand writes:
> Currently if qemu-img convert is used to convert for example a qcow1
> image (with a backing file) to a qcow2 image, the resulting image
> will have no backing file.

This kind of thing ought to be discussed with qemu upstream too,
surely ?  Perhaps even implemented there first.

> In order to preserve the backing file (to save disk space), qemu-img
> should offer a command line option to enable the feature. For this
> it needs to be made aware of BlockDrivers supporting backing files.

The best way to do this will probably involve a certain amount of
restructuring of the interface to the block drivers.  So definitely
something to discuss with upstream.

Ian.

Re: [Qemu-devel] [RFC] Allow 'qemu-img convert' to preserve the backing file

[Ian Jackson]

I wrote:
> The best way to do this will probably involve a certain amount of
> restructuring of the interface to the block drivers.  So definitely
> something to discuss with upstream.

Ignore all that.

I thought I was replying to a message on the xen-devel list.
Sorry, I'm very thickheaded today.

Right, changing context:

> Marc Bevand <m.bevand@gmail.com>:
> > In order to preserve the backing file (to save disk space),
> > qemu-img should offer a command line option to enable the
> > feature. For this it needs to be made aware of BlockDrivers
> > supporting backing files.

If there were a generic way to ask a block driver for a cow format
what the backing image filename was, then the block driver core could
do the opening itself.  That would make everything a bit simpler as it
would move code out of the invididual drivers.

Ian.

[Qemu-devel] Re: [RFC] Allow 'qemu-img convert' to preserve the backing file

[Marc Bevand]

Ian Jackson <Ian.Jackson <at> eu.citrix.com> writes:
> 
> If there were a generic way to ask a block driver for a cow format
> what the backing image filename was, then the block driver core could
> do the opening itself.  That would make everything a bit simpler as it
> would move code out of the invididual drivers.

I am done. I implemented this feature in a generic way as you suggested. I am
going to send the patch in a separate email. I am confident in its robustness,
so far I have successfully converted more than 20 copy-on-write qcow1 images to
the qcow2 format. Different sizes, different "ages" (between 0 and 90% of the
sectors rewritten in the COW copies), different guest filesystems, etc. I have
verified no corruption occured by making sure a final conversion to the raw
format led to the expected MD5 checksum.

-marc

[Qemu-devel] [PATCH] New qemu-img convert -B option to preserve the COW aspect of images and/or re-base them

[Marc Bevand]

(Ignore my first email, the patch has been mangled. Get it from:
http://etud.epita.fr/~bevand_m/pub/rebase-cow-disk-image.patch )


If a disk image hd_a is a copy-on-write image based on the backing
file hd_base, it is currently impossible to use qemu-img to convert
hd_a to hd_b (possibly using another disk image format) while keeping
hd_b a copy-on-write image of hd_base. qemu-img also doesn't provide a
feature that would let an enduser re-base a image, for example: adjust
hd_a's backing file name from hd_base to hd_base2 if it had to change
for some reason.

This patch solves the 2 above problems by adding a new qemu-img
convert -B option which works as described below. This is a generic
feature that should work with ANY disk image format supporting backing
files:

  -B output_base_image
     forces the output image to be created as a copy on write image of
     the specified base image; 'output_base_image' should have the
     same content as the input's base image, however the path, image
     format, etc may differ

Examples:

  $ qemu-img info hd_a
  image: hd_a
  file format: qcow
  virtual size: 6.0G (6442450944 bytes)
  disk size: 28K
  cluster_size: 512
  backing file: hd_base (actual path: hd_base)

Converting hd_a (qcow) to hd_b (qcow2) while preserving the
copy-on-write aspect of the image:

  $ qemu-img convert hd_a -O qcow2 -B hd_base hd_b
  $ qemu-img info hd_b
  image: hd_b
  file format: qcow2
  virtual size: 6.0G (6442450944 bytes)
  disk size: 36K
  cluster_size: 4096
  backing file: hd_base (actual path: hd_base)

Renaming the backing file without losing hd_a:

  $ ln hd_base hd_base2
  $ qemu-img convert hd_a -O qcow -B hd_base2 hd_a2
  $ mv hd_a2 hd_a
  $ rm hd_base
  $ qemu-img info hd_a
  image: hd_a
  file format: qcow
  virtual size: 6.0G (6442450944 bytes)
  disk size: 28K
  cluster_size: 512
  backing file: hd_base2 (actual path: hd_base2)

Patch made against SVN's rev 4622.


Signed-off-by: Marc Bevand <m.bevand <at> gmail.com>

Get it from: http://etud.epita.fr/~bevand_m/pub/rebase-cow-disk-image.patch

Re: [Qemu-devel] [RFC] Allow 'qemu-img convert' to preserve the backing file

[Jamie Lokier]

Ian Jackson wrote:
> So definitely something to discuss with upstream.

Is qemu-devel not the most upstream place for qemu development?

(By the way, vpc format is broken in qemu-img.  Should I not be
reporting it on qemu-devel then, but somewhere else?)

-- Jamie

Re: [Qemu-devel] [RFC] Allow 'qemu-img convert' to preserve the backing file

[Ian Jackson]

Jamie Lokier writes ("Re: [Qemu-devel] [RFC] Allow 'qemu-img convert' to preserve the backing file"):
> Ian Jackson wrote:
> > So definitely something to discuss with upstream.
> 
> Is qemu-devel not the most upstream place for qemu development?

As I said, I was confused and thought I was reading and replying to
xen-devel.  Obviously qemu-devel is the right place.

Ian.