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 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 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 > . > + > + 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