From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43329) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2QoV-0001CQ-W4 for qemu-devel@nongnu.org; Tue, 28 Feb 2012 12:26:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2QoT-0005Pk-Ts for qemu-devel@nongnu.org; Tue, 28 Feb 2012 12:26:11 -0500 Received: from mail-ee0-f45.google.com ([74.125.83.45]:61190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2QoT-0005Pb-IR for qemu-devel@nongnu.org; Tue, 28 Feb 2012 12:26:09 -0500 Received: by eeit10 with SMTP id t10so2328781eei.4 for ; Tue, 28 Feb 2012 09:26:07 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4F4D0E2C.5040202@redhat.com> Date: Tue, 28 Feb 2012 18:26:04 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1329930815-7995-1-git-send-email-fsimonce@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Live Block Migration using Mirroring List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, Federico Simoncelli , mtosatti@redhat.com, qemu-devel@nongnu.org Il 28/02/2012 16:47, Stefan Hajnoczi ha scritto: > At this stage we have dst/hd0snap1 opened with BDRV_O_NO_BACKING. If > it has no backing file and the guest issues a write request that is > smaller than a cluster in the image file, the untouched areas of that > cluster will be populated with zeroes. > > Once dst/hd0snap1 is reopened with dst/hd0base in place there will be > zeros in clusters where the guest wrote only a few sectors. We will > not "see" the backing file data in those clusters. > > Have you hit this problem or did I miss something? I'm afraid not. Federico, perhaps you have to rewrite blkmirror to reuse copy-on-read mechanism. You can implement is_allocated and make the base image a real backing_file even though you can write to it. Perhaps some hack with BDRV_O_NO_BACKING, or perhaps it just works with Jeff's open-on-top behavior. Looks like it would also make streaming of the base image Just Work, at least to a non-raw destination. Remaining problems: 1) differentiating writes from copy-on-read and writes from the guest. This is needed to avoid spurious writes to the backing image each time you're doing a copy-on-read. 2) triggering a copy-on-read before writing partial clusters. Stefan, what do you think? Paolo