From: Robert Wang <wdongxu@linux.vnet.ibm.com>
To: Frediano Ziglio <freddy77@gmail.com>
Cc: kwolf@redhat.com, Marcelo Tosatti <mtosatti@redhat.com>,
qemu-devel@nongnu.org,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>,
Ming M Shu <shuming@cn.ibm.com>
Subject: Re: [Qemu-devel] External COW format for raw images
Date: Wed, 20 Jul 2011 15:27:13 +0800 [thread overview]
Message-ID: <1311146833.4188.3.camel@wdongxu-T410> (raw)
In-Reply-To: <CAHt6W4dUSnWTrEgB0Y93-8+cfA17TboFEFXBa46+bxWEhm2mzw@mail.gmail.com>
On Tue, 2011-07-19 at 16:39 +0200, Frediano Ziglio wrote:
> 2011/7/19 Robert Wang <wdongxu@linux.vnet.ibm.com>:
> > 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;
> > };
> > * 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.
> >
> > Do you think my approach is right?
> > Thank you.
> >
>
> I don't understand if you mean just a way to track clusters/sectors
> changed or a new way to implement snapshotting, something that writing
> data just store original to cow like like:
>
>
> normal backfile
>
> is allocated on image
> write to image
> else
> allocate on image
> copy from backing to image
> write to image (patch before previous write)
>
> cow-raw (inverse backfile)
>
> is allocated on image
> write to backing
> else
> allocate on image
> copy from backing to image
> write to backing
>
>
> that is
>
>
> is not allocated on image
> allocate on image
> copy from backing to image
> is normal backing
> write to image
> else
> write to backing
>
>
> Frediano
>
Frediano, it mainly is to track clusters/sectors changes, not a new way
to implement snapshotting.
prev parent reply other threads:[~2011-07-20 7:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-19 9:25 [Qemu-devel] External COW format for raw images Robert Wang
2011-07-19 9:55 ` Stefan Hajnoczi
2011-07-19 10:28 ` Kevin Wolf
2011-07-19 13:20 ` Anthony Liguori
2011-07-20 8:35 ` Stefan Hajnoczi
2011-07-20 15:57 ` Marcelo Tosatti
2011-07-26 10:16 ` Stefan Hajnoczi
2011-07-19 14:39 ` Frediano Ziglio
2011-07-20 7:27 ` Robert Wang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1311146833.4188.3.camel@wdongxu-T410 \
--to=wdongxu@linux.vnet.ibm.com \
--cc=freddy77@gmail.com \
--cc=kwolf@redhat.com \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=shuming@cn.ibm.com \
--cc=stefanha@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).