qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Kevin Wolf
Subject: Re: [Qemu-devel] External COW format for raw images
Date: Tue, 19 Jul 2011 12:28:57 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc15 Thunderbird/3.1.10

Am 19.07.2011 11:25, schrieb Robert Wang:
> 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

Just one comment for the start: This is not only useful for raw (while
certainly being the most important case), but also for every other image
format for which qemu doesn't support backing files.

This means that we should look for a better name than raw-cow. I know,
it was me who introduced this, but only for lack of a better name.

> 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.

Can't this be private to the COW driver? It certainly will have a
BDRVRawCowState or something like that.

> 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.

I think it's better to keep drivers cleanly separated. If we really need
to share code, we should provide some sort of a library that is used by
both, but I doubt that it's required in this case.

What the driver should probably do, is to open the raw file internally
and keep a BlockDriverState of the raw file in its private structure.
For all accesses to the raw file, use the "official" interfaces of the
raw driver, like bdrv_aio_readv/writev.

>  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 don't think any of mtime, size and sectorsize are necessary. They will
just be taken from the raw file (if needed at all).

> };
>       * Struct raw_cow_create_options should be one member plus based on
> cow_create_options:
> {
> .name = BLOCK_OPT_RAW_FILE,
> .type = OPT_STRING,
> .help = "Raw file name"
> },
> 
> 3) Add bdrv_get_raw_filename in img_info function of qemu-img.c. In
> bdrv_get_raw_filename, if the format of the image file is "raw-cow",
> print the related raw file.

Hm... Won't be implemented by any other driver, but I guess it makes
some sense to provide this information.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]