qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC PATCH] replication agent module


From: Ori Mamluk
Subject: Re: [Qemu-devel] [RFC PATCH] replication agent module
Date: Tue, 07 Feb 2012 16:48:46 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

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 need, no?

Yes, with two NBD sockets you could do it. But would you use both at the same time? I would have thought that either the rephub is streaming from the protected volume, or QEMU is streaming to the rephub.

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 concurrently protects new IOs.
With a 'new' agent like I need this is relatively easily achieved by a
bidirectional protocol, but I agree a more generic protocol would be
more elegant, although it will probably require a socket per direction, no?

I Some smaller questions:
* Is there already a working iScsi initiator as a block driver (I hope
I'm using the right terminology) in Qemu, or do I need to write one?

Yes, there is one using libiscsi. But I think Anthony was not referring to iSCSI in particular, NBD would work just as well.

* This driver would need to be added in run-time - to allow starting to
protect a running VM. Maybe via a monitor command. I guess that's OK,
right?

Yes, I think you can detach a block device from a drive and reattach the new mirroring device.

* What can you say about NBD via iScsi - with respect to our
requirements- who is more mature in Qemu?

Personally I prefer NBD because it is lighter-weight and there is a server inside QEMU (so you can use it easily with non-raw images). It is more mature, but it is a bit less extensible.

I think we don't need an extensible or rich API, so NBD may fit. I'll look deeper into it.
One more thing about the iScsi initiator - it will not be a standard
backing for a drive, because the 'production' drive (i.e. the original
image) is more important than the replicated one. This means that even
though we use iScsi, this is still a replication agent - not a generic
'additional' iscsi backing.

Yes, understood.

Paolo




reply via email to

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