On 24/05/2012 16:41, Paolo Bonzini wrote:
The dirty bitmap is managed by these QMP commands:
* blockdev-dirty-enable: takes a file name used for the dirty bitmap,
and an optional granularity. Setting the granularity will not be
supported in the initial version.
* query-block-dirty: returns sta
Added qemu license to all files
Changed int to bool for flags
---
block/repagent/qemu-repagent.txt | 16 --
block/repagent/repagent.c| 39
++---
block/repagent/repagent.h|7 +++--
block/repagent/repagent_client.c | 35
Used as repagent patch v3
---
block/repagent/repagent.c|4 ++--
block/repagent/repagent.h|2 +-
block/repagent/repagent_client.c | 35 ---
3 files changed, 11 insertions(+), 30 deletions(-)
diff --git a/block/repagent/repagent.c b/blo
---
Makefile.objs |2 +-
block.c |7 ++-
block.h |1 +
block/repagent/repagent_drv.c | 197
+
blockdev.c|6 ++
vl.c | 15 +++
6 files
Use set_fd_handler instead of a listening thread.
Change the reading/parsing function to be state-machine based, because they
no longer have their own thread.
---
Makefile |6 +-
Makefile.objs | 10 +-
configure |3 +-
replicatio
On 03/03/2012 13:46, Stefan Hajnoczi wrote:
On Wed, Feb 29, 2012 at 8:38 AM, Ori Mamluk wrote:
I think the BlockFilter direction goes very well with our plans for a
replication module.
I guess it would take some discussions and time to form a solid layer for
the BlockFilters, and I'd li
Hi Kevin and all,
I think the BlockFilter direction goes very well with our plans for a
replication module.
I guess it would take some discussions and time to form a solid layer
for the BlockFilters, and I'd like to move ahead in parallel with the
replication module.
What do you say about the
On 21/02/2012 11:49, Kevin Wolf wrote:
Am 21.02.2012 10:15, schrieb Paolo Bonzini:
So maybe we just need to extend the current BlockDriverState stack to
distinguish "normal" and "always on top" BlockDrivers, where the latter
would roughly correspond to BlockListeners?
I would prefer having sepa
On 08/02/2012 16:59, Stefan Hajnoczi wrote:
On Wed, Feb 8, 2012 at 1:28 PM, Ori Mamluk wrote:
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
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 contr
Hi,
Following previous mails from Kevin and Dor, I'd like to specify the
high level requirements of a replication agent as I see them.
1. Report each write to a protected volume to the rephub, at an IO
transaction granularity
* The reporting is not synchronous, i.e. the write completion is
On 08/02/2012 10:55, Kevin Wolf wrote:
Am 08.02.2012 07:10, schrieb Ori Mamluk:
On 07/02/2012 17:47, Paolo Bonzini wrote:
Why can't QEMU itself stream the full volume in the background, and
send that together with any new I/O? Is it because the rephub knows
which parts are out-of-dat
On 07/02/2012 17:47, Paolo Bonzini wrote:
On 02/07/2012 03:48 PM, Ori Mamluk wrote:
The current streaming code in QEMU only deals with the former.
Streaming to a remote server would not be supported.
I need it at the same time. The Rephub reads either the full volume or
parts of, and
On 07/02/2012 16:40, Paolo Bonzini wrote:
On 02/07/2012 03:06 PM, Ori Mamluk wrote:
The main issue about it is that the Rephub also needs the other
direction - to read the protected volume. I get the feeling that with
live block copy and NBD there's probably something that might fit
this
On 07/02/2012 15:34, Kevin Wolf wrote:
Am 07.02.2012 11:29, schrieb Ori Mamluk:
Repagent is a new module that allows an external replication system to
replicate a volume of a Qemu VM.
This RFC patch adds the repagent client module to Qemu.
Documentation of the module role and API is in the
On 07/02/2012 15:50, Stefan Hajnoczi wrote:
First let me say that I'm not completely used to the inline replies - so
I initially missed some of your mail before.
On Tue, Feb 7, 2012 at 1:34 PM, Kevin Wolf wrote:
Am 07.02.2012 11:29, schrieb Ori Mamluk:
Repagent is a new module that a
On 07/02/2012 14:40, Anthony Liguori wrote:
On 02/07/2012 06:30 AM, Ori Mamluk wrote:
In addition, I don't see that the listener thread holds any lock while
it reads the image. I guess that during that period the guest runs
and may
race w/ this new thread.
Yes - I mentioned that in the
nction I call from a new thread
context is bdrv_aio_readv.
-Original Message-
From: Dor Laor [mailto:dl...@redhat.com]
Sent: Tuesday, February 07, 2012 2:25 PM
To: Anthony Liguori
Cc: Ori Mamluk; Kevin Wolf; qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module
18 matches
Mail list logo
