From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2aDf-0005xN-HI for qemu-devel@nongnu.org; Tue, 17 May 2016 04:19:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2aDd-0003m2-29 for qemu-devel@nongnu.org; Tue, 17 May 2016 04:19:10 -0400 Date: Tue, 17 May 2016 10:18:57 +0200 From: Kevin Wolf Message-ID: <20160517081857.GA5260@noname.redhat.com> References: <21631668.b5e2.154613e9ee1.Coremail.zhangzhiming865@163.com> <20160503084432.GC3917@noname.str.redhat.com> <84BBC559-EC88-42C6-A267-29B0942C64E3@meituan.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <84BBC559-EC88-42C6-A267-29B0942C64E3@meituan.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] qcow2 resize with snapshots List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: zhangzhiming Cc: qemu-devel@nongnu.org, lihuiba , qemu-block@nongnu.org Am 16.05.2016 um 08:33 hat zhangzhiming geschrieben: > hi, i read some source code by your tips, and i have some conclusions: >=20 > 1. Old version of QCOW2 image does not store the total size of snapshot= , so, we > can=E2=80=99t=20 > add the function to the old version of QEMU, and the function of QC= OW2 > resize with snapshots=20 > will be limited in V3 image or it will make confusion. so that is r= ight. > 2. I read the source code of bdrv_truncate from master, and the functio= n > =E2=80=9Cbdrv_dirty_bitmap_truncate" have done this, so=20 > it means that i need not to consider the resize of bitmap while res= ize > 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 =E2=80=9Cqmp_marshal_block_resize=E2=80=9D= ,=20 > this function will block IO requests when resizing a image, and it = seems > that it called callback function to notify the=20 > guest, and we don=E2=80=99t need to set BLOCK_OP_TYPE_RESIZE blocke= rs. 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 =3D 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 > wrote: >=20 > sorry, i forgot to cc qemu-block@nongnu.org. >=20 > zhangzhiming > zhangzhiming02@meituan.com >=20 >=20 >=20 >=20 > On May 7, 2016, at 10:47 AM, zhangzhiming > wrote: >=20 > thank you for your reply, and i am glad to join to the developm= ent of > qemu. > i will try my best to finish this new function. >=20 > have a good day! >=20 > zhangzhiming > zhangzhiming02@meituan.com >=20 >=20 >=20 >=20 > On May 3, 2016, at 4:44 PM, Kevin Wolf w= rote: >=20 > [ Cc: qemu-block ] >=20 > Am 29.04.2016 um 10:59 hat zhangzm geschrieben: >=20 > hi, i want to implement the function of qcow2 resize wh= ich has > snapshots. >=20 > 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. >=20 > now, there is a disk_size value in struct QcowSnapshot,= i only > need to > change the size of current active image layer when appl= y a > snapshot > with different size, and the io request will be limit i= n the > range of > active layer. >=20 >=20 > Yes, I think today the qcow2 format provides everything tha= t 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 (t= his > field did > not exist in v2 images yet). >=20 > What you need to consider is that loading a snapshot become= s > similar to > resizing an image then and you need to do the same things f= or it. > For > example, we need to figure out what to do with associated d= irty > bitmaps > (adapt them to the new size like in bdrv_truncate()?), call= resize > callbacks so that the guest devices actually see the change= s size > and > possibly also consider the BLOCK_OP_TYPE_RESIZE blockers to= prevent > a > size change while the image is in use. >=20 >=20 > and i want my code merged into the master of qemu. >=20 >=20 > The wiki has a few tips on how to submit patches for qemu: > http://wiki.qemu.org/Contribute/SubmitAPatch >=20 > For a patch (or patch series) like this, you will want to C= C at > least > qemu-block and qemu-devel, plus possibly a few individual p= eople. >=20 > Kevin >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20