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

[Stefan Hajnoczi]

On Wed, Jul 20, 2011 at 4:57 PM, Marcelo Tosatti <address@hidden> wrote:
> 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?

Anthony, could you elaborate what you meant?

Stefan