Re: [Qemu-devel] External COW format for raw images

[Marcelo Tosatti]

On Wed, Jul 20, 2011 at 09:35:05AM +0100, Stefan Hajnoczi wrote:
> 2011/7/19 Anthony Liguori <address@hidden>:
> > On 07/19/2011 04:25 AM, Robert Wang wrote:
> >> As you known, raw image is very popular,but the raw image format does
> >> NOT support Copy-On-Write,a raw image file can NOT be used as a copy
> >> destination, then image streaming/Live Block Copy will NOT work.
> >>
> >> To fix this, we need to add a new block driver raw-cow to QEMU. If
> >> finished, we can use qemu-img like this:
> >> qemu-img create -f raw-cow -o backing_file=ubuntu.img,raw_file=my_vm.img
> >> my_vm.raw-cow
> >>
> >> 1) ubuntu.img is the backing file, my_vm.img is a raw file,
> >> my_vm.raw-cow stores a COW bitmap related to my_vm.img.
> >>
> >> 2) If the entire COW bitmap is set to dirty flag then we can get all
> >> information from my_vm.img and can ignore ubuntu.img and my_vm.raw-cow
> >> from now.
> >>
> >> To implement this, I think I can follow these steps:
> >> 1) Add a new member to BlockDriverState struct:
> >> char raw_file[1024];
> >> This member will track raw_file parameter related to raw-cow file from
> >> command line.
> >>
> >> 2)    * Create a new file block/raw-cow.c. It will be much more like the
> >> mixture of block/cow.c and block/raw.c.
> >>
> >> So I will change some functions in cow.c and raw.c to none-static, then
> >> raw-cow.c can re-use them. When read operation occurs, determine whether
> >> dirty flag in raw-cow image is set. If true, read directly from the raw
> >> file. After write operation, set related dirty flag in raw-cow image.
> >> And other functions might also be modified.
> >>
> >>       * Of course, format_name member of BlockDriver struct will be 
> >> "raw-cow".
> >> And in order to keep relationship with raw file( like my_vm.img) ,
> >> raw_cow_header struct should be
> >> struct raw_cow_header {
> >> uint32_t magic;
> >> uint32_t version;
> >> char backing_file[1024];
> >> char raw_file[1024];/* added*/
> >> int32_t mtime;
> >> uint64_t size;
> >> uint32_t sectorsize;
> >> };
> >
> > I'd suggest that doing an image format is the wrong approach here.  Why
> > not just have a image format where you can pass it the location of a
> > bitmap?  That let's you compose arbitrarily complex backing file chains
> > and avoids the introduce of a new bitmap.

Its possible to implement backing file chains in any case, no need for 
separate bitmap on-disk.

> > The bitmap format is also useful for implementing things like dirty
> > tracking.
> 
> Are you describing something like -drive
> file=bitmap:raw.img:backing.img:dirty.bmap?
> 
> Stefan

The bitmap (whether its separate or part of the image) is intimately
related to the raw file, and the relation is specific indicating
allocated status.

Perhaps what Anthony is suggesting is an interface for on-disk bitmap
access, with caching?