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