From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMAGY-0005CX-HU for qemu-devel@nongnu.org; Fri, 13 Feb 2015 02:02:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMAGV-0002TZ-8O for qemu-devel@nongnu.org; Fri, 13 Feb 2015 02:02:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMAGV-0002TJ-1L for qemu-devel@nongnu.org; Fri, 13 Feb 2015 02:02:15 -0500 Date: Fri, 13 Feb 2015 15:01:49 +0800 From: Fam Zheng Message-ID: <20150213070149.GA24580@ad.nay.redhat.com> References: <1423710438-14377-1-git-send-email-wency@cn.fujitsu.com> <1423710438-14377-2-git-send-email-wency@cn.fujitsu.com> <20150212072117.GB32554@ad.nay.redhat.com> <54DC58E6.7060608@cn.fujitsu.com> <20150212084435.GD32554@ad.nay.redhat.com> <54DC7376.9060300@cn.fujitsu.com> <20150212094432.GA21253@ad.nay.redhat.com> <54DC7C39.40101@cn.fujitsu.com> <20150212102622.GA24218@ad.nay.redhat.com> <54DD871D.10708@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54DD871D.10708@cn.fujitsu.com> Subject: Re: [Qemu-devel] [RFC PATCH 01/14] docs: block replication's description List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Kevin Wolf , Lai Jiangshan , Jiang Yunhong , Dong Eddie , "Dr. David Alan Gilbert" , qemu devel , Gonglei , Stefan Hajnoczi , Paolo Bonzini , Yang Hongyang , jsnow@redhat.com, zhanghailiang On Fri, 02/13 13:09, Wen Congyang wrote: > What is image fleecing? > It's the name of the feature which enables the built-in NBD server to exporting a thin point-in-time snapshot created via drive-backup sync=none. It's for host side data scanning tool to access a disk snapshot of running VM. The workflow in theory is: 1. guest uses "disk0" as its virtio-blk device. 2. in qmp, use blockdev-add (drive-backup) to add an empty "target0" qcow2 image, that uses "disk0" as its backing file, and use nbd-server-add to export this empty image with NBD. This way, all reads coming from NBD client will produce data of "disk0". 3. in qmp, start blockdev-backup from "disk0" to "target0" with "sync=none". After this point, all guest data written to "disk0" will COW the original data to "target0", in other words, reading "target0" will effectively produce a point-in-time snapshot of the time when blockdev-backup started. 4. after step 3, the disk data seen by the NBD client is the stable snapshot. Because of the COW mechanism in blockdev-backup, "target0" is thin, and can be dropped once the inspection process is done. > Are you implementing it now? I worked on it. Most parts of the series is merged, the remaining part is relatively small, namely to 1) enable adding "target0" in step 2 (currently in blockdev-add it's not possible to reference an existing drive as backing file); 2) enable "blockdev-backup" from "disk0" to "target0", which is obviously not possible because 1) is not done. I do have the patches at my tree, just that they need to be refreshed. :) https://github.com/famz/qemu/tree/image-fleecing Fam