From: Kevin Wolf <kwolf@redhat.com>
To: zhangzhiming <zhangzhiming02@daodian.dxvip.meituan.com>
Cc: qemu-devel@nongnu.org,
lihuiba <lihuiba@daodian.dxvip.meituan.com>,
qemu-block@nongnu.org
Subject: Re: [Qemu-devel] qcow2 resize with snapshots
Date: Tue, 17 May 2016 10:18:57 +0200 [thread overview]
Message-ID: <20160517081857.GA5260@noname.redhat.com> (raw)
In-Reply-To: <84BBC559-EC88-42C6-A267-29B0942C64E3@meituan.com>
Am 16.05.2016 um 08:33 hat zhangzhiming geschrieben:
> hi, i read some source code by your tips, and i have some conclusions:
>
> 1. Old version of QCOW2 image does not store the total size of snapshot, so, we
> can’t
> add the function to the old version of QEMU, and the function of QCOW2
> resize with snapshots
> will be limited in V3 image or it will make confusion. so that is right.
> 2. I read the source code of bdrv_truncate from master, and the function
> “bdrv_dirty_bitmap_truncate" have done this, so
> it means that i need not to consider the resize of bitmap while resize
> QCOW2 ?
This is correct, qcow2_truncate() does not need to consider it.
However, snapshot loading must consider it. Essentially, when allowing
snapshots with different image sizes, qcow2_snapshot_goto() is an
implicit resize as well, even though it doesn't go through
bdrv_truncate().
> 3. there is a function named “qmp_marshal_block_resize”,
> this function will block IO requests when resizing a image, and it seems
> that it called callback function to notify the
> guest, and we don’t need to set BLOCK_OP_TYPE_RESIZE blockers. is it
> correct ?
I think you mean qmp_block_resize(). (This is the function that is
called by the automatically generated qmp_marshal_block_resize().)
For the same reason as above (snapshot loading = implicit resize), we
need to check the blocker and call the callbacks for snapshot loading
now.
Kevin
> On May 7, 2016, at 11:13 AM, zhangzhiming <zhangzhiming02@meituan.com>
> wrote:
>
> sorry, i forgot to cc qemu-block@nongnu.org.
>
> zhangzhiming
> zhangzhiming02@meituan.com
>
>
>
>
> On May 7, 2016, at 10:47 AM, zhangzhiming <zhangzhiming02@meituan.com>
> wrote:
>
> thank you for your reply, and i am glad to join to the development of
> qemu.
> i will try my best to finish this new function.
>
> have a good day!
>
> zhangzhiming
> zhangzhiming02@meituan.com
>
>
>
>
> On May 3, 2016, at 4:44 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>
> [ Cc: qemu-block ]
>
> Am 29.04.2016 um 10:59 hat zhangzm geschrieben:
>
> hi, i want to implement the function of qcow2 resize which has
> snapshots.
>
> each snapshot of qcow2 will have a separate total size, and
> when apply
> a snapshot, the image can be shrunk, and the total size of
> image will
> change after apply to a snapshot with different size.
>
> now, there is a disk_size value in struct QcowSnapshot, i only
> need to
> change the size of current active image layer when apply a
> snapshot
> with different size, and the io request will be limit in the
> range of
> active layer.
>
>
> Yes, I think today the qcow2 format provides everything that is
> needed
> to implement this. You need to make sure that we have a v3 image so
> that
> the virtual disk size is actually stored in the snapshot (this
> field did
> not exist in v2 images yet).
>
> What you need to consider is that loading a snapshot becomes
> similar to
> resizing an image then and you need to do the same things for it.
> For
> example, we need to figure out what to do with associated dirty
> bitmaps
> (adapt them to the new size like in bdrv_truncate()?), call resize
> callbacks so that the guest devices actually see the changes size
> and
> possibly also consider the BLOCK_OP_TYPE_RESIZE blockers to prevent
> a
> size change while the image is in use.
>
>
> and i want my code merged into the master of qemu.
>
>
> The wiki has a few tips on how to submit patches for qemu:
> http://wiki.qemu.org/Contribute/SubmitAPatch
>
> For a patch (or patch series) like this, you will want to CC at
> least
> qemu-block and qemu-devel, plus possibly a few individual people.
>
> Kevin
>
>
>
>
>
>
>
>
next prev parent reply other threads:[~2016-05-17 8:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-29 8:59 [Qemu-devel] qcow2 resize with snapshots zhangzm
2016-05-03 8:44 ` Kevin Wolf
2016-05-07 2:47 ` zhangzhiming
2016-05-07 3:13 ` zhangzhiming
2016-05-16 6:33 ` zhangzhiming
2016-05-17 8:18 ` Kevin Wolf [this message]
-- strict thread matches above, loose matches on Subject: below --
2016-05-06 5:57 zhangzhiming
2016-05-06 11:20 ` Kevin Wolf
2016-05-07 2:52 ` zhangzhiming
2016-04-29 7:55 zhangzm
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=20160517081857.GA5260@noname.redhat.com \
--to=kwolf@redhat.com \
--cc=lihuiba@daodian.dxvip.meituan.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=zhangzhiming02@daodian.dxvip.meituan.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).