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

[Eric Blake]

On 01/13/2016 02:18 AM, Changlong Xie wrote:
> From: Wen Congyang 
> 
> Signed-off-by: Wen Congyang 
> Signed-off-by: zhanghailiang 
> Signed-off-by: Gonglei 
> Signed-off-by: Changlong Xie 
> ---
>  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 000..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?

> +
> +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/

> +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/

> +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.

> +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=,file.port=,file.export=colo1,node-name=nbd_client1,if=none'

Eww. We shouldn't ever have to pack a command line as a 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': '',
  ... } } }

> +  }
> +}
> +{ '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 

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

[Eric Blake]

On 02/02/2016 08:18 PM, Changlong Xie wrote:
> On 02/02/2016 11:20 PM, Eric Blake wrote:
>> On 01/13/2016 02:18 AM, Changlong Xie wrote:
>>> From: Wen Congyang 
>>>
>>> Signed-off-by: Wen Congyang 
>>> Signed-off-by: zhanghailiang 
>>> Signed-off-by: Gonglei 
>>> Signed-off-by: Changlong Xie 
>>> ---
>>>   docs/block-replication.txt | 229

>>> +== 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=,file.port=,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': '',
> 
> Hi Eric
> 
> What is 'remote-command' here? I just tried below commands, but got some
> errors.

Oh, I totally missed that this was using the existing
'human-monitor-command' to send an HMP command, instead of trying to
send a formal QMP command.  I thought you were documenting a new QMP
command.

Still, it would be nice to do this command using strict QMP (that would
be via 'blockdev-add') rather than via HMP (an all-in-one text command
crammed into the single 'command-line' argument).

> 
> '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:

For 2.6, we _really_ ought to get blockdev-add working for everything.
We're running short on time, though :(

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

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

[Wen Congyang]

On 02/03/2016 11:35 AM, Eric Blake wrote:
> On 02/02/2016 08:18 PM, Changlong Xie wrote:
>> On 02/02/2016 11:20 PM, Eric Blake wrote:
>>> On 01/13/2016 02:18 AM, Changlong Xie wrote:
 From: Wen Congyang 

 Signed-off-by: Wen Congyang 
 Signed-off-by: zhanghailiang 
 Signed-off-by: Gonglei 
 Signed-off-by: Changlong Xie 
 ---
   docs/block-replication.txt | 229
> 
 +== 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=,file.port=,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': '',
>>
>> Hi Eric
>>
>> What is 'remote-command' here? I just tried below commands, but got some
>> errors.
> 
> Oh, I totally missed that this was using the existing
> 'human-monitor-command' to send an HMP command, instead of trying to
> send a formal QMP command.  I thought you were documenting a new QMP
> command.
> 
> Still, it would be nice to do this command using strict QMP (that would
> be via 'blockdev-add') rather than via HMP (an all-in-one text command
> crammed into the single 'command-line' argument).
> 
>>
>> '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:
> 
> For 2.6, we _really_ ought to get blockdev-add working for everything.
> We're running short on time, though :(
> 

If the qmp command 'blockdev-add' supports nbd in qemu-2.6, we will update
this document when it is suppoted.

Thanks
Wen Congyang

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 

Signed-off-by: Wen Congyang 
Signed-off-by: zhanghailiang 
Signed-off-by: Gonglei 
Signed-off-by: Changlong Xie 
---
  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 000..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=,file.port=,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': '',


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" } }

<- {