On Fri, Jan 20, 2017 at 11:47:59AM +0800, zhanghailiang wrote: > Just as the scenario of non-shared disk block replication, > we are going to implement block replication from many basic > blocks that are already in QEMU. > The architecture is: > > virtio-blk || > .---------- > / || | > Secondary > / || > '---------- > / || > virtio-blk > / || > | > | || > replication(5) > | NBD --------> NBD (2) > | > | client || server ---> hidden disk <-- > active disk(4) > | ^ || | > | replication(1) || | > | | || | > | +-----------------' || | > (3) |drive-backup sync=none || | > --------. | +-----------------+ || | > Primary | | | || backing | > --------' | | || | > V | | > +-------------------------------------------+ | > | shared disk | <----------+ > +-------------------------------------------+ > > 1) Primary writes will read original data and forward it to Secondary > QEMU. > 2) The hidden-disk is created automatically. It buffers the original > content > that is modified by the primary VM. It should also be an empty disk, > and > the driver supports bdrv_make_empty() and backing file. > 3) Primary write requests will be written to Shared disk. > 4) Secondary write requests will be buffered in the active disk and it > will overwrite the existing sector content in the buffer. > > Signed-off-by: zhanghailiang <zhang.zhanghaili...@huawei.com> > Signed-off-by: Wen Congyang <we...@cn.fujitsu.com> > Signed-off-by: Zhang Chen <zhangchen.f...@cn.fujitsu.com>
Are there any restrictions on the shared disk? For example the -drive cache= mode must be 'none'. If the cache mode isn't 'none' the secondary host might have old data in the host page cache. The Secondary QEMU would have an inconsistent view of the shared disk. Are image file formats like qcow2 supported for the shared disk? Extra steps are required to achieve consistency, see bdrv_invalidate_cache(). Stefan
signature.asc
Description: PGP signature
