Re: [Qemu-devel] [PATCH v14 5/8] docs: block replication's description

[Changlong Xie]

On 02/02/2016 11:20 PM, Eric Blake wrote:
> On 01/13/2016 02:18 AM, Changlong Xie wrote:
> > From: Wen Congyang <address@hidden>
> >
> > Signed-off-by: Wen Congyang <address@hidden>
> > Signed-off-by: zhanghailiang <address@hidden>
> > Signed-off-by: Gonglei <address@hidden>
> > Signed-off-by: Changlong Xie <address@hidden>
> > ---
> >   docs/block-replication.txt | 229 +++++++++++++++++++++++++++++++++++++++++++++
> >   1 file changed, 229 insertions(+)
> >   create mode 100644 docs/block-replication.txt
> >
> > diff --git a/docs/block-replication.txt b/docs/block-replication.txt
> > new file mode 100644
> > index 0000000..d1a231e
> > --- /dev/null
> > +++ b/docs/block-replication.txt
> > @@ -0,0 +1,229 @@
> > +Block replication
> > +----------------------------------------
> > +Copyright Fujitsu, Corp. 2015
> > +Copyright (c) 2015 Intel Corporation
> > +Copyright (c) 2015 HUAWEI TECHNOLOGIES CO., LTD.
>
> Do you want to claim 2016 for any of this?

Will update in next version.

> > +
> > +This work is licensed under the terms of the GNU GPL, version 2 or later.
> > +See the COPYING file in the top-level directory.
> > +
> > +Block replication is used for continuous checkpoints. It is designed
> > +for COLO (COarse-grain LOck-stepping) where the Secondary VM is running.
> > +It can also be applied for FT/HA (Fault-tolerance/High Assurance) scenario,
> > +where the Secondary VM is not running.
> > +
> > +This document gives an overview of block replication's design.
> > +
> > +== Background ==
> > +High availability solutions such as micro checkpoint and COLO will do
> > +consecutive checkpoints. The VM state of Primary VM and Secondary VM is
>
> s/of Primary/of the Primary/

OK

> > +identical right after a VM checkpoint, but becomes different as the VM
> > +executes till the next checkpoint. To support disk contents checkpoint,
> > +the modified disk contents in the Secondary VM must be buffered, and are
> > +only dropped at next checkpoint time. To reduce the network transportation
> > +effort at the time of checkpoint, the disk modification operations of
>
> s/at the time of/during a vmstate/
> s/operations of/operations of the/

OK

> > +Primary disk are asynchronously forwarded to the Secondary node.
> > +
> > +== Workflow ==
>
> > +== Architecture ==
>
> > +
> > +6) The drive-backup job(sync=none) is run to allow hidden-disk to buffer
>
> Space before ( in English description.

OK

> > +any state that would otherwise be lost by the speculative write-through
> > +of the NBD server into the secondary disk. So before block replication,
> > +the primary disk and secondary disk should contain the same data.
> > +
> > +== Failure Handling ==
>
> > +== Usage ==
> > +Primary:
> > +  -drive if=xxx,driver=quorum,read-pattern=fifo,id=colo1,vote-threshold=1,\
> > +         children.0.file.filename=1.raw,\
> > +         children.0.driver=raw
> > +
> > +  Run qmp command in primary qemu:
> > +    { 'execute': 'human-monitor-command',
> > +      'arguments': {
> > +          'command-line': 'drive_add buddy 
> > driver=replication,mode=primary,file.driver=nbd,file.host=xxxx,file.port=xxxx,file.export=colo1,node-name=nbd_client1,if=none'
>
> Eww. We shouldn't ever have to pack a command line as . single QMP
> string that needs reparsing.  Instead, you should pass the information
> as a nested QMP dictionary, something like:
>
> 'arguments': {
>    'remote-command': { 'command': 'drive_add', 'name': 'buddy',
>                        'driver': 'replication', 'mode': 'primary',
>                        'file': { 'driver': 'nbd', 'host': 'xxxx',

Hi Eric

What is 'remote-command' here? I just tried below commands, but got some 
errors.

{'execute': 'human-monitor-command',
    'arguments': {
       'command-line': {
            'command': 'drive_add',
            'name': 'buddy',
            'driver': 'replication',
            'mode': 'primary',
            'if': 'none',
            'node-name': 'primary_nbd_node',
            'file': {
                'driver': 'nbd',
                'host': '192.168.3.2',
                'port': '8889',
                'export': 'colo-disk',
            }

        }
     }
}
{"error": {"class": "GenericError", "desc": "Invalid JSON syntax"}}           


'blockdev-add' doesn't support 'nbd'. So we use 'drive_add' here, and 
it's a hmp command. If i'm right, there seems just one way to execute 
hmp commands in QMP:

================================================================
EQMP

    {
        .name       = "human-monitor-command",
        .args_type  = "command-line:s,cpu-index:i?",
        .mhandler.cmd_new = qmp_marshal_human_monitor_command,
    },

SQMP
human-monitor-command
---------------------

Execute a Human Monitor command.

Arguments:

- command-line: the command name and its arguments, just like the
                Human Monitor's shell (json-string)
- cpu-index: select the CPU number to be used by commands which access CPU
             data, like 'info registers'. The Monitor selects CPU 0 if this
             argument is not provided (json-int, optional)

Example:

-> { "execute": "human-monitor-command", "arguments": { "command-line": 
"info kvm" } }
<- { "return": "kvm support: enabled\r\n" }
==================================================================

                
Thanks
        -Xie


>    ... } } }
>
> > +      }
> > +    }
> > +    { 'execute': 'x-blockdev-change',
> > +      'arguments': {
> > +          'parent': 'colo1',
> > +          'node': 'nbd_client1'
> > +      }
> > +    }
> > +  Note:
> > +  1. There should be only one NBD Client for each primary disk.
> > +  2. host is the secondary physical machine's hostname or IP
> > +  3. Each disk must have its own export name.
> > +  4. It is all a single argument to -drive and you should ignore the
> > +     leading whitespace.
> > +  5. The qmp command line must be run after running qmp command line in
> > +     secondary qemu.
> > +
> > +Secondary:
> > +  -drive if=none,driver=raw,file.filename=1.raw,id=colo1 \
> > +  -drive if=xxx,driver=replication,mode=secondary,\
> > +         file.file.filename=active_disk.qcow2,\
> > +         file.driver=qcow2,\
> > +         file.backing.file.filename=hidden_disk.qcow2,\
> > +         file.backing.driver=qcow2,\
> > +         file.backing.backing=colo1
> > +
> > +  Then run qmp command in secondary qemu:
> > +    { 'execute': 'nbd-server-start',
> > +      'arguments': {
> > +          'addr': {
> > +              'type': 'inet',
> > +              'data': {
> > +                  'host': 'xxx',
> > +                  'port': 'xxx'
> > +              }
> > +          }
> > +      }
> > +    }
> > +    { 'execute': 'nbd-server-add',
> > +      'arguments': {
> > +          'device': 'colo1',
> > +          'writable': true
> > +      }
> > +    }
> > +
> > +  Note:
> > +  1. The export name in secondary QEMU command line is the secondary
> > +     disk's id.
> > +  2. The export name for the same disk must be the same
> > +  3. The qmp command nbd-server-start and nbd-server-add must be run
> > +     before running the qmp command migrate on primary QEMU
> > +  4. Active disk, hidden disk and nbd target's length should be the
> > +     same.
> > +  5. It is better to put active disk and hidden disk in ramdisk.
> > +  6. It is all a single argument to -drive, and you should ignore
> > +     the leading whitespace.
> > +
> > +After Failover:
> > +Primary:
> > +  The secondary host is down, so we should run the following qmp command
> > +  to remove the nbd child from the quorum:
> > +  { 'execute': 'x-blockdev-change',
> > +    'arguments': {
> > +        'parent': 'colo1',
> > +        'child': 'children.1'
> > +    }
> > +  }
> > +  Note: there is no qmp command to remove the blockdev now
> > +
> > +Secondary:
> > +  The primary host is down, so we should do the following thing:
> > +  { 'execute': 'nbd-server-stop' }
> > +
> > +TODO:
> > +1. Continuous block replication
> > +2. Shared disk