qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
> 
> 
> 
> 
> 
> 
> 
> 

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