Re: [Qemu-devel] [RFC PATCH v2] Replication agent module

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 5999 bytes --]

On 04/01/2012 06:05 AM, Ori Mamluk wrote:
> Repagent is a new block driver that allows an external replication system
> to hook to the Qemu storage stack to replicate a volume of a VM.
> This RFC patch adds the repagent client module to Qemu.
> 

Completely non-technical review of just your documentation (that is, I
have no opinions on the code or the technical validity of things, but
will leave that to the block layer experts):

> 
> From: Ori Mamluk <orim@orim-fedora.(none)>

Fix your git setup to use a valid email for author.

> 
> Added replication agent module to Qemu
> 
> Added build options to ./configure:  --enable-replication
> --disable-replicat

Are these intended to be asymmetrical spellings?

> Added a commandline option to enable: -repagent <rep hub IP>

Is this always an IP address and port number, or can it also be a file
descriptor?

> +++ b/block/repagent/qemu-repagent.txt
> @@ -0,0 +1,73 @@
> +    repagent - replication agent - a Qemu module for enabling continuous
> async replication of VM volumes
> +
> +Introduction
> +    This document describes a feature in Qemu - a replication agent
> (named Repagent).
> +    The Repagent is a new module that exposes an API to an external
> replication system (AKA Rephub).
> +    This API allows a Rephub to communicate with a Qemu VM and
> continuously replicate its volumes.
> +    The imlementation of a Rephub is outside of the scope of this

s/imlementation/implementation/

> document. There may be several various Rephub
> +    implenetations using the same repagent in Qemu.

s/implenetations/implementations/

> +    The Repagent is storage driver that acts like a filter driver.
> +    It can be regarded as a 'plugin' that is activated when the
> management system enables replication.
> +
> +Main feature of Repagent
> +    Repagent has the following main features:
> +    * Report volumes - report a list of all volumes in a VM to the
> Rephub.
> +    * Mirror writes - Report writes to a volume - send all writes made to
> a protected volume to the Rephub.
> +        The reporting of an IO is asyncronuous - i.e. the IO is not

s/asyncronuous/asynchronous/

> delayed by the Repagent to get any acknowledgement from the Rephub.

s/acknowledgement/acknowledgment/

long lines; it would be worth re-wrapping this text

> +        It is only copied to the Rephub.
> +    * Remote IO - Read/write a  volume - allows the Rephub to read a
> protected volume, to enable the protected hub to syncronize

s/syncronize/synchronize/

> +       the content of a protected volume.
> +       Also used to read/write to a recovery volume - the replica of a
> protected volume.
> +
> +Description of the Repagent module
> +
> +Build and run options
> +    New configure option: --enable-repagent
> +    New command line option:
> +    -repagent [hub IP/name]
> +                    Enable replication support for disks
> +                    hub is the ip or name of the machine running the
> replication hub.

port number? Can we pass in an already-opened socket fd?

> +
> +Module APIs
> +    The Repagent module interfaces two main components:
> +    1. The Rephub - An external API based on socket messages
> +           See detailed comments about each message in rephub_cmds.h
> +    2. The generic block layer- block.c
> +        Repagent is a block driver. Most of the block driver functions
> are just a pass-through
> +        to the next driver.
> +        Writes are mirrors to the hub for replication
> +        Open function is used for registering each volume in Repagent.
> +
> +
> +General description of a Rephub  - a replication system the repagent
> connects to
> +    This section describes in high level a sample Rephub - a replication
> system that uses the repagent API
> +    to replicate disks.
> +    It describes a simple Rephub that comntinuously maintains a mirror of

s/comntinuously/continuously/

> the volumes of a VM.
> +
> +    Say we have a VM we want to protect - call it PVM, say it has 2
> volumes - V1, V2.
> +    Our Rephub is called SingleRephub - a Rephub protecting a single VM.
> +
> +    Preparations
> +    1. The user chooses a host to rub SingleRephub - a different host

s/rub/run/

> than PVM, call it Host2
> +    2. The user creates two volumes on Host2 - same sizes of V1 and V2,
> call them V1R (V1 recovery) and V2R.
> +    3. The user runs SingleRephub process on Host2, and gives V1R and V2R
> as command line arguments.
> +        From now on SingleRephub waits for the protected VM repagent to
> connect.
> +    4. The user runs the protected VM PVM - and uses the switch -repagent
> <Host2 IP>.
> +
> +    Runtime
> +    1. The repagent module connects to SingleRephub on startup.
> +    2. repagent reports V1 and V2 to SingleRephub.
> +    3. SingleRephub starts to perform an initial synchronization of the
> protected volumes-
> +        it reads each protected volume (V1 and V2) - using read volume
> requests - and copies the data into the
> +        recovery volume V1R and V2R.
> +    4. SingleRephub enters 'protection' mode - each write to the
> protected volume is sent by the repagent to the Rephub,
> +        and the Rephub performs the write on the matching recovery
> volume.
> +
> +    * Note that during stage 3 writes to the protected volumes are not
> ignored - they're kept in a bitmap,
> +        and will be read again when stage 3 ends, in an interative
> convergin process.

s/convergin/converging/

> +
> +    This flow continuously maintains an updated recovery volume.
> +    If the protected system is damaged, the user can create a new VM on
> Host2 with the replicated volumes attached to it.
> +    The new VM is a replica of the protected system.
> +
> +

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]