From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrnUP-0003pm-Bk for qemu-devel@nongnu.org; Thu, 19 Jul 2012 05:57:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SrnUJ-00010e-88 for qemu-devel@nongnu.org; Thu, 19 Jul 2012 05:57:45 -0400 Received: from mail-lb0-f173.google.com ([209.85.217.173]:59475) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SrnUI-00010M-W4 for qemu-devel@nongnu.org; Thu, 19 Jul 2012 05:57:39 -0400 Received: by lbok6 with SMTP id k6so3833748lbo.4 for ; Thu, 19 Jul 2012 02:57:37 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1339598189-17933-1-git-send-email-wdongxu@linux.vnet.ibm.com> <1339598189-17933-5-git-send-email-wdongxu@linux.vnet.ibm.com> <4FD9C40C.1@redhat.com> <4FD9C8A0.6080504@redhat.com> <4FD9CC26.3040306@redhat.com> Date: Thu, 19 Jul 2012 10:57:37 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCH 5/6] add-cow: support snapshot_blkdev List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dong Xu Wang Cc: Kevin Wolf , Paolo Bonzini , qemu-devel@nongnu.org, Stefan Hajnoczi On Thu, Jul 19, 2012 at 3:20 AM, Dong Xu Wang wrote: > On Thu, Jun 14, 2012 at 7:33 PM, Kevin Wolf wrote: >> Am 14.06.2012 13:18, schrieb Paolo Bonzini: >>> Il 14/06/2012 12:59, Kevin Wolf ha scritto: >>>> Am 13.06.2012 16:36, schrieb Dong Xu Wang: >>>>> add-cow will let raw file support snapshot_blkdev indirectly. >>>>> >>>>> Signed-off-by: Dong Xu Wang >>>> >>>> Paolo, what do you think about this magic? >>> >>> Besides the obvious layering violation (it would be better to add a new >>> method bdrv_ext_snapshot_create perhaps) I don't see very much a problem >>> in it. Passing image creation options sounds like a good idea that we >>> can add in the future as an extension. >>> >>> But honestly, I don't really see the point of add-cow in general... The >>> raw image is anyway not usable without a pass through qemu-io convert, >>> and mirroring will also allow collapsing an image to raw (with the >>> persistent dirty bitmap playing the role of the add-cow metadata). >> >> Well, the idea was that you stream into add-cow and once the streaming >> has completed, you can just drop the bitmap. >> >> There might be some overlap with mirroring, though when we discussed >> introducing add-cow, mirrors were not yet on the table. One difference >> that remains is that with streaming the guest only writes to the target >> image and can't have any problem with convergence. >> >>>> I think I can see its use especially for HMP because it's quite >>>> convenient, but on the other hand it assumes a fixed image path for the >>>> new raw image. This isn't going to work for block devices, for example. >>> >>> True, but then probably you would use mode='existing', because you need >>> to pre-create the logical volume. >> >> I think it might be convenient to have the raw volume precreated (you >> need to do that anyway), but create the COW bitmap only during the >> snapshot command. But yeah, not really important. >> >>>> If we don't do it this way, we need to allow passing image creation >>>> options to the snapshotting command so that you can pass a precreated >>>> image file. >>> >>> This sounds like a useful extension anyway, except that passing an >>> unstructured string for image creation options is ugly... Perhaps we >>> can base a better implementation of options on Laszlo's QemuOpts visitor. >> >> Yes, I wouldn't want to use a string here, we should use something >> structured. Image creation still uses the old-style options instead of >> QemuOpts, but maybe this is the opportunity to convert it. > > Kevin, do you mean I need to replace QEMUOptionParameter with QemuOpts? > > If true, other image formats should also be changed, I noticed Stefan > has an un-comleted patch: > http://repo.or.cz/w/qemu/stefanha.git/commitdiff/b49babb2c8b476a36357cfd7276ca45a11039ca5 > > then I can work based on Stefan's patch. It's been a while so I don't remember details, but if you want to discuss more let me know and I'll refresh my memory. Stefan