Re: [Qemu-devel] [Qemu-block] [PATCH v3 5/6] replication: Implement block replication for shared disk case

[Stefan Hajnoczi <stefanha@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3816 bytes --]

On Tue, Mar 07, 2017 at 10:30:30PM +0800, Hailiang Zhang wrote:
> Hi Stefan,
> 
> Sorry for the delayed reply.
> 
> On 2017/2/28 1:37, Stefan Hajnoczi wrote:
> > 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.zhanghailiang@huawei.com>
> > > Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
> > > Signed-off-by: Zhang Chen <zhangchen.fnst@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
> 
> While do checkpoint, we will call vm_stop(), in which, the bdrv_flush_all()
> will be called, is it enough ?
> 
> > Secondary QEMU would have an inconsistent view of the shared disk.
> > 
> > Are image file formats like qcow2 supported for the shared disk?  Extra
> 
> In the above scenario, it has no limitation of formats for the shared disk.
> 
> > steps are required to achieve consistency, see bdrv_invalidate_cache().
> > 
> 
> Hmm, in that case, we should call bdrv_invalidate_cache_all() while checkpoint.

Yes, it's not enough to just call bdrv_drain_all()/bdrv_flush_all().
The Secondary may need to reread metadata that is loaded in memory (e.g.
qcow2's L2 table cache) so bdrv_invalidate_cache() is needed.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]