From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45654) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv7Zy-00010n-KS for qemu-devel@nongnu.org; Wed, 08 Feb 2012 08:29:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv7Zs-0007qQ-RZ for qemu-devel@nongnu.org; Wed, 08 Feb 2012 08:28:58 -0500 Received: from mail-bk0-f45.google.com ([209.85.214.45]:64082) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv7Zs-0007q6-LZ for qemu-devel@nongnu.org; Wed, 08 Feb 2012 08:28:52 -0500 Received: by bkue19 with SMTP id e19so352896bku.4 for ; Wed, 08 Feb 2012 05:28:51 -0800 (PST) Message-ID: <4F32788C.60904@zerto.com> Date: Wed, 08 Feb 2012 15:28:44 +0200 From: Ori Mamluk MIME-Version: 1.0 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> <4F323875.1000000@redhat.com> <4F3244C2.1040604@zerto.com> <4F32489A.80307@redhat.com> In-Reply-To: <4F32489A.80307@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: dlaor@redhat.com, =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , =?UTF-8?B?16rXldee16gg15HXnyDXkNeV?= =?UTF-8?B?16g=?= , qemu-devel@nongnu.org, Yair Kuszpet , Paolo Bonzini Hi, Thanks for all the valuable inputs provided so far, I'll try to suggest a design based on them. The main inputs were about the use a new transport protocol between repagent and rephub. It was suggested to use some standard network storage protocol instead, and use QMP commands for the control path. The main idea is to use two NBD connections per protected volume: NBD tap - protected VM is the client, rephub is the server, used to report writes. The tap is not a standard NBD backing - it is for replication, meaning that its importance is lesser than the main image path. Errors are not reported to the protected VM as IO error. NBD reader - protected VM is the server, rephub is the client, used for reading the protected volume. The NBD reader is a generic remote read (can add also write) capability, probably usable for other various needs. Actually the reader will probably be more useful as a reader/writer, but for the agent - only read is required. Here's a list of the protocol messages from the previous design and how they're implemented in this design: Rephub --> Repagent: * Start protect Will be done via QMP command. * Read volume request Covered by NBD reader Repagent --> Rephub * Protected write Covered by NBD tap * Report VM volumes Isn't required in the protocol. I assume the management system tracks the volumes * Read Volume Response Covered by NBD tap * Agent shutdown Not covered. The start protect scenario will look something like: * User calls start protect for a volume * Mgmt system (e.g. Rhev) sends QMP command to VM - start protect, with volume details (path) and a IP+port number for NBD tap --> Qemu connects to the NBD tap server * Mgmt system sends QMP command to VM - start remote reader with volume details and port number for NBD reader. --> Qemu starts to listen as an NBD server on that port Issues: * As far as I understand, NBD requires socket/port per volume, which the management system allocates. This is a little cumbersome The original design had a single server in the rephub - a single port allocation, and a socket per Qemu. Appreciate any comments and ideas. Thanks, Ori