On Tue, Feb 7, 2012 at 2:59 PM, Anthony Liguori<address@hidden> wrote:
On 02/07/2012 07:50 AM, Stefan Hajnoczi wrote:
On Tue, Feb 7, 2012 at 1:34 PM, Kevin Wolf<address@hidden> 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.
I recently joked with Kevin that QEMU is on its way to reimplementing
the Linux block and device-mapper layers. Now we have drbd, thanks!
:P
I don't think it's a joke. Do we really want to get into this space? Why
not just use drbd?
If it's because we want to also work with image formats, perhaps we should
export our image format code as a shared library and let drbd link against
it.
When the guest disk image is on an LVM volume the picture looks like this:
Guest -> QEMU -> drbd -> LVM volume
When an image file is in use we need a way for Linux to access it:
Guest -> QEMU -> drbd -> local NBD server
The local NBD server runs the qcow2, qed, etc code.
Both scenarios are possible today without modifications to QEMU code.
For reference, here is the drbd website http://www.drbd.org/, it's
described as "network based raid-1".
Looking seriously at drbd is worthwhile because it already implements
the advanced features that this prototype patch omits. Take a look at
the documentation at http://www.drbd.org/docs/working/. Checksums,
rate of synchronization, congestion policies, I/O error handling
policies, and so on are all supported already.
I suspect using drbd would require more management stack integration
rather than QEMU patches. For example, libvirt would need to launch
NBD servers and drbd.