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

[Stefan Hajnoczi <stefanha@gmail.com>]

2012/2/8 Dor Laor <dlaor@redhat.com>:
> On 02/08/2012 08:10 AM, Ori Mamluk wrote:
>>
>> 2. drbd is 'below' all the Qemu block layers - if the protected volume
>> is qcow2 then drbd doesn't get the raw IOs, right?
>
>
> That's one of the major caveats in drbd/iscsi/nbd - there is no support for
> block level snapshots[1]. I wonder if the scsi protocol has something like
> this so we'll get efficient replication of qcow2/lvm snapshots that their
> base is already shared. If we'll gain such functionality, we'll benefit of
> it for storage vm motion solution too.

In the case of copy-on-write disk images we do want to mirror all
writes because, by definition, they are not shared.  I think the
trickier part is how to do the initial synchronization without copying
the entire backing file.

> Another issue w/ drbd is that a continuous backup solution requires to do
> consistent snapshot and call file system freeze and sync it w/ the current
> block IO transfer. DRBD doesn't do that nor the other protocols. Of course
> DRBD can be enhanced but it will take allot more time.

Ori's patch simply mirrors writes, it doesn't have any higher-level
consistent snapshot support either.  Consistent snapshots are
different from continuous backups - I thought these were being
addressed with completely separate QMP and guest agent commands?

> A third requirement and similar to above is to group snapshots of several
> VMs so a consistent _cross vm application view_ will be created. It demands
> some control over IO tagging.

If I understand correctly this means being able to go back to time T
across multiple VMs' volumes.  That sounds like a timestamping issue
and is mainly a server-side feature, the agent is not involved.

> To summarize, IMHO drbd (which I used successfully 6 years ago and I love)
> is not drop&replace solution to this case.
> I recommend we either to fit the nbd/iscsi case and improve our vm storage
> motion on the way or worse case develop proprietary logic that can live out
> side of qemu using IO tapping interface, similar to the guidelines Ori
> outlines.

Perhaps we can figure out how to make this replication functionality
fit in with image streaming and block migration.  If it provides
generally useful functionality (outside of just the replication case)
then that would be worth adding to QEMU because it would be useful
beyond drbd territory.

Stefan