qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replica


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module)
Date: Wed, 8 Feb 2012 14:59:03 +0000

On Wed, Feb 8, 2012 at 1:28 PM, Ori Mamluk <address@hidden> wrote:
> 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.

You mentioned a future feature that sends request metadata (offset,
length) to the rephub synchronously so that protection is 100%.
(Otherwise a network failure or crash might result in missed writes
that the rephub does not know about.)

The NBD tap might not be the right channel for sending synchronous
request metadata, since the protocol is geared towards block I/O
requests that include the actual data.  I'm not sure that QMP should
be used either - even though we have the concept of QMP events -
because it's not a low-latency, high ops communications channel.

Which channel do you use in your existing products for synchronous
request metadata?

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]