From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Runrp-0007oI-BU for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:26:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Runri-0007Oo-V0 for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:26:05 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:56035) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Runri-0007Od-QE for qemu-devel@nongnu.org; Tue, 07 Feb 2012 11:25:58 -0500 Received: by pbaa11 with SMTP id a11so8057013pba.4 for ; Tue, 07 Feb 2012 08:25:57 -0800 (PST) Message-ID: <4F315091.40806@codemonkey.ws> Date: Tue, 07 Feb 2012 10:25:53 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <73865e0ce364c40e0eb65ec6b22b819d@mail.gmail.com> <4F312854.3080404@redhat.com> <4F313C69.1050203@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , dlaor@redhat.com, qemu-devel@nongnu.org, Ori Mamluk , Luiz Capitulino On 02/07/2012 09:20 AM, Stefan Hajnoczi wrote: > On Tue, Feb 7, 2012 at 2:59 PM, Anthony Liguori wrote: >> On 02/07/2012 07:50 AM, Stefan Hajnoczi wrote: >>> >>> On Tue, Feb 7, 2012 at 1:34 PM, Kevin Wolf wrote: >>>> >>>> Am 07.02.2012 11:29, schrieb Ori Mamluk: >>>>> >>>>> Repagent is a new module that allows an external replication system to >>>>> replicate a volume of a Qemu VM. >>> >>> >>> I recently joked with Kevin that QEMU is on its way to reimplementing >>> the Linux block and device-mapper layers. Now we have drbd, thanks! >>> :P >> >> >> I don't think it's a joke. Do we really want to get into this space? Why >> not just use drbd? >> >> If it's because we want to also work with image formats, perhaps we should >> export our image format code as a shared library and let drbd link against >> it. > > When the guest disk image is on an LVM volume the picture looks like this: > > Guest -> QEMU -> drbd -> LVM volume > > When an image file is in use we need a way for Linux to access it: > > Guest -> QEMU -> drbd -> local NBD server > > The local NBD server runs the qcow2, qed, etc code. > > Both scenarios are possible today without modifications to QEMU code. > > For reference, here is the drbd website http://www.drbd.org/, it's > described as "network based raid-1". > > Looking seriously at drbd is worthwhile because it already implements > the advanced features that this prototype patch omits. Take a look at > the documentation at http://www.drbd.org/docs/working/. Checksums, > rate of synchronization, congestion policies, I/O error handling > policies, and so on are all supported already. > > I suspect using drbd would require more management stack integration > rather than QEMU patches. For example, libvirt would need to launch > NBD servers and drbd. I don't have a problem with a libqemu that presented an easy to use interface for libvirt to consume.... But NIH justified with the fact that we can provide a single management interface isn't a good justification IMHO. Regards, Anthony Liguori > > Stefan >