From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53016) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv6BF-0004eR-VD for qemu-devel@nongnu.org; Wed, 08 Feb 2012 06:59:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv6BE-0003AM-Jv for qemu-devel@nongnu.org; Wed, 08 Feb 2012 06:59:21 -0500 Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]:38245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv6BE-0003AG-Ds for qemu-devel@nongnu.org; Wed, 08 Feb 2012 06:59:20 -0500 Received: by lahi5 with SMTP id i5so426436lah.4 for ; Wed, 08 Feb 2012 03:59:19 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4F323712.1030409@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> <4F323712.1030409@redhat.com> Date: Wed, 8 Feb 2012 11:59:18 +0000 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: Kevin Wolf , =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , =?UTF-8?B?16rXldee16gg15HXnyDXkNeV16g=?= , qemu-devel@nongnu.org, Ori Mamluk , Yair Kuszpet , Paolo Bonzini 2012/2/8 Dor Laor : > On 02/08/2012 08:10 AM, Ori Mamluk wrote: >> >> 2. drbd is 'below' all the Qemu block layers - if the protected volume >> is qcow2 then drbd doesn't get the raw IOs, right? > > > That's one of the major caveats in drbd/iscsi/nbd - there is no support for > block level snapshots[1]. I wonder if the scsi protocol has something like > this so we'll get efficient replication of qcow2/lvm snapshots that their > base is already shared. If we'll gain such functionality, we'll benefit of > it for storage vm motion solution too. In the case of copy-on-write disk images we do want to mirror all writes because, by definition, they are not shared. I think the trickier part is how to do the initial synchronization without copying the entire backing file. > Another issue w/ drbd is that a continuous backup solution requires to do > consistent snapshot and call file system freeze and sync it w/ the current > block IO transfer. DRBD doesn't do that nor the other protocols. Of course > DRBD can be enhanced but it will take allot more time. Ori's patch simply mirrors writes, it doesn't have any higher-level consistent snapshot support either. Consistent snapshots are different from continuous backups - I thought these were being addressed with completely separate QMP and guest agent commands? > A third requirement and similar to above is to group snapshots of several > VMs so a consistent _cross vm application view_ will be created. It demands > some control over IO tagging. If I understand correctly this means being able to go back to time T across multiple VMs' volumes. That sounds like a timestamping issue and is mainly a server-side feature, the agent is not involved. > To summarize, IMHO drbd (which I used successfully 6 years ago and I love) > is not drop&replace solution to this case. > I recommend we either to fit the nbd/iscsi case and improve our vm storage > motion on the way or worse case develop proprietary logic that can live out > side of qemu using IO tapping interface, similar to the guidelines Ori > outlines. Perhaps we can figure out how to make this replication functionality fit in with image streaming and block migration. If it provides generally useful functionality (outside of just the replication case) then that would be worth adding to QEMU because it would be useful beyond drbd territory. Stefan