From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv8gk-0006RJ-85 for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:40:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv8ge-0007CH-CD for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:40:01 -0500 Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]:50283) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv8ge-0007Bp-4J for qemu-devel@nongnu.org; Wed, 08 Feb 2012 09:39:56 -0500 Received: by lahi5 with SMTP id i5so570135lah.4 for ; Wed, 08 Feb 2012 06:39:54 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4F326E99.7030904@redhat.com> References: <73865e0ce364c40e0eb65ec6b22b819d@mail.gmail.com> <4F31153E.9010205@codemonkey.ws> <4F311839.9030709@redhat.com> <4F311BBA.8000708@codemonkey.ws> <4F312FD3.5020206@zerto.com> <4F3137DB.1040503@redhat.com> <4F3139CE.4040103@zerto.com> <4F314798.8010009@redhat.com> <4F3211D0.3070502@zerto.com> <4F326E99.7030904@redhat.com> Date: Wed, 8 Feb 2012 14:39:54 +0000 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Kevin Wolf , =?UTF-8?B?16rXldee16gg15HXnyDXkNeV16g=?= , =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , dlaor@redhat.com, qemu-devel@nongnu.org, Ori Mamluk , Yair Kuszpet On Wed, Feb 8, 2012 at 12:46 PM, Paolo Bonzini wrote: > On 02/08/2012 01:03 PM, Stefan Hajnoczi wrote: >> >> If you intend to run an unmodified drbd server on the rephub, then it >> may not be possible to get point-in-time backups. =A0(Although this >> probably depends since things like btrfs or zfs may allow you to get >> back to arbitrary transactions or timestamps.) > > > I'm not sure what's the overhead, but btrfs copy-on-write (reflinks) may > help. > > >> But you could consider drbd as a network protocol and implement your >> own server which speaks the protocol. =A0Then you can add any >> functionality you like, just like the case with the proprietary rephub >> server you mentioned in your patch. >> >> So the only difference is that instead of using a new custom protocol >> the rephub would need to speak the drbd protocol. > > > So you're suggesting DRBD-over-NBD on the client, and for the replication > hub a custom server speaking the DRBD protocol? =A0I didn't find any > documentation for DRBD and the code is only in the kernel, so this sounds > like a lot of work. Adding code to QEMU is definitely the easiest solution. I'm just not sure whether it's the right one if this will evolve to have the same features as drbd. > What about taking the existing Ceph/RBD driver in QEMU and changing it to > support arbitrary image formats rather than just raw? =A0That sounds much= much > easier. =A0The main advantage is that Ceph has a user-space library for u= se in > the replication hub. =A0It also supports snapshots. I missed how Ceph/RBD helps. Can you explain how we would use it? Stefan