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