[Top][All Lists]

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

Re: [Qemu-devel] qcow2 resize with snapshots

From: Kevin Wolf
Subject: Re: [Qemu-devel] qcow2 resize with snapshots
Date: Tue, 17 May 2016 10:18:57 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

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

> 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


>     On May 7, 2016, at 11:13 AM, zhangzhiming <address@hidden>
>     wrote:
>     sorry, i forgot to cc address@hidden
>     zhangzhiming
>     address@hidden
>         On May 7, 2016, at 10:47 AM, zhangzhiming <address@hidden>
>         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
>         address@hidden
>             On May 3, 2016, at 4:44 PM, Kevin Wolf <address@hidden> 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 via email to

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