From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53709) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXuW4-00038b-0D for qemu-devel@nongnu.org; Fri, 25 May 2012 09:25:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXuVx-0003CX-Qw for qemu-devel@nongnu.org; Fri, 25 May 2012 09:25:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXuVx-0003C8-J1 for qemu-devel@nongnu.org; Fri, 25 May 2012 09:25:09 -0400 Message-ID: <4FBF882F.5020008@redhat.com> Date: Fri, 25 May 2012 15:25:03 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4FB6821A.1080902@redhat.com> <4FBE3A89.8020702@redhat.com> <20120525094357.GC30110@stefanha-thinkpad.localdomain> <4FBF6A30.90505@redhat.com> <20120525120958.GA4376@stefanha-thinkpad.localdomain> In-Reply-To: <20120525120958.GA4376@stefanha-thinkpad.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Eric Blake , qemu-devel , Ori Mamluk , Luiz Capitulino Il 25/05/2012 14:09, Stefan Hajnoczi ha scritto: >> > >> > Perhaps that be simply a new qemu-img subcommand? It should be possible >> > to run it while the VM is offline. Then the file that is produced could >> > be fed to blockdev-dirty-enable. > For both continuous replication and incremental backups we cannot > require that the guest is shut down in order to collect the dirty > bitmap, I think. Yes, that is a problem for internal snapshots. For external snapshots, see the drive-mirror command's sync parameter. Perhaps we can add a blockdev-dirty-fill command that adds allocated sectors up to a given base to the dirty bitmap. > I think we really need a libvirt API because a local file not only has > permissions issues but also is not network transparent. The continuous > replication server runs on another machine, how will it access the dirty > bitmap file? This is still using a "push" model where the dirty data is sent from QEMU to the replication server, so the dirty bitmap is not needed on the machine that runs the replication server---only on the machine that runs the VM (to preserve the bitmap across VM shutdowns including power loss). It has to be stored on shared storage if you plan to run the VM from multiple hosts. Paolo