From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50188) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V06bQ-0002TI-ON for qemu-devel@nongnu.org; Fri, 19 Jul 2013 05:03:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V06bM-0006dK-2V for qemu-devel@nongnu.org; Fri, 19 Jul 2013 05:03:52 -0400 Received: from e28smtp07.in.ibm.com ([122.248.162.7]:51490) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V06bL-0006cM-FF for qemu-devel@nongnu.org; Fri, 19 Jul 2013 05:03:48 -0400 Received: from /spool/local by e28smtp07.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 19 Jul 2013 14:25:51 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id 8D4781258043 for ; Fri, 19 Jul 2013 14:33:03 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r6J94R2I28835900 for ; Fri, 19 Jul 2013 14:34:28 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r6J93bhZ009242 for ; Fri, 19 Jul 2013 19:03:38 +1000 Message-ID: <51E900D3.30705@linux.vnet.ibm.com> Date: Fri, 19 Jul 2013 17:03:15 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1374069835-14287-1-git-send-email-xiawenc@linux.vnet.ibm.com> <20130718054350.GE26971@stefanha-thinkpad.redhat.com> In-Reply-To: <20130718054350.GE26971@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 0/4] export internal snapshot by qemu-nbd List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, dietmar@proxmox.com 于 2013-7-18 13:43, Stefan Hajnoczi 写道: > On Wed, Jul 17, 2013 at 10:03:51PM +0800, Wenchao Xia wrote: >> This series allow user to read internal snapshot's contents without qemu-img >> convert. Another purpose is that, when qemu is online and have taken an >> internal snapshot, let user invoke qemu-nbd to do any thing on it except write. > > I agree with Eric and Kevin that we cannot access image files while QEMU > has them open. > > A bit more detail about using the run-time NBD server to do this safely: > > Internal snapshots are not first-class block layer objects today. They > are not BlockDriverStates, instead you must access their data through > bdrv_snapshot_goto() or bdrv_snapshot_load_tmp(). > Also cc to Fam Zheng an Kevin: I think BlockDriverStates modification, is based on a more basic question: does qcow2's data structure on disk, allow multiple snapshot reader, while one active writer, without lock? I think the modification showed above, already said "yes" to this question. If yes, just create a new BlockDriverStates, we should say yes in spec. I wonder how vmdk allow direct snapshot access by VixDiskLib 1.1, without network expense on host, it should be the format said support of it. > The problem with these functions is that they use the BlockDriverState. > So the guest cannot write to the main image while an internal snapshot > is loaded. > > This can be solved by introducing a function that creates a read-only > internal snapshot BlockDriverState which is partially independent of the > main image BlockDriverState that the guest is accessing. > > The challenge is implementing this cleanly: > > 1. The lifecycle of the main image BlockDriverState and the read-only > internal snapshot BlockDriverState is related. What happens when the > main image BDS is deleted but the snapshot BDS is still alive? What > happens when bdrv_snapshot_delete() is called while the BDS snapshot > exists? > > 2. At what level should resources like the bs->file and metadata caches > (L1/L2/refcount) be shared? If they are shared it's easy to keep > them consistent but makes lifecycle handling harder. > > Stefan > -- Best Regards Wenchao Xia