On Wed, Jul 20, 2011 at 4:57 PM, Marcelo Tosatti <mtosa...@redhat.com> wrote: > On Wed, Jul 20, 2011 at 09:35:05AM +0100, Stefan Hajnoczi wrote: >> 2011/7/19 Anthony Liguori <anth...@codemonkey.ws>: >> > 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