Reviewed-by: Fabiano Rosas <farosas@suse.de>
Signed-off-by: Lukas Straub <lukasstraub2@web.de>
---
MAINTAINERS | 2 +-
docs/COLO-FT.txt | 334 ------------------------------------------
docs/system/index.rst | 1 +
docs/system/qemu-colo.rst | 360 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 362 insertions(+), 335 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8e63e0a08fc7417036986f27c2d910eb99d8a96a..f645590b8b940919bdc84ad585ee493f5452fc20 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3855,7 +3855,7 @@ F: migration/multifd-colo.*
F: include/migration/colo.h
F: include/migration/failover.h
F: tests/qtest/migration/colo-tests.c
-F: docs/COLO-FT.txt
+F: docs/system/qemu-colo.rst
COLO Proxy
M: Zhang Chen <zhangckid@gmail.com>
diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt
deleted file mode 100644
index 2283a09c080b8996f9767eeb415e8d4fbdc940af..0000000000000000000000000000000000000000
--- a/docs/COLO-FT.txt
+++ /dev/null
@@ -1,334 +0,0 @@
-COarse-grained LOck-stepping Virtual Machines for Non-stop Service
-----------------------------------------
-Copyright (c) 2016 Intel Corporation
-Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
-Copyright (c) 2016 Fujitsu, Corp.
-
-This work is licensed under the terms of the GNU GPL, version 2 or later.
-See the COPYING file in the top-level directory.
-
-This document gives an overview of COLO's design and how to use it.
-
-== Background ==
-Virtual machine (VM) replication is a well known technique for providing
-application-agnostic software-implemented hardware fault tolerance,
-also known as "non-stop service".
-
-COLO (COarse-grained LOck-stepping) is a high availability solution.
-Both primary VM (PVM) and secondary VM (SVM) run in parallel. They receive the
-same request from client, and generate response in parallel too.
-If the response packets from PVM and SVM are identical, they are released
-immediately. Otherwise, a VM checkpoint (on demand) is conducted.
-
-== Architecture ==
-
-The architecture of COLO is shown in the diagram below.
-It consists of a pair of networked physical nodes:
-The primary node running the PVM, and the secondary node running the SVM
-to maintain a valid replica of the PVM.
-PVM and SVM execute in parallel and generate output of response packets for
-client requests according to the application semantics.
-
-The incoming packets from the client or external network are received by the
-primary node, and then forwarded to the secondary node, so that both the PVM
-and the SVM are stimulated with the same requests.
-
-COLO receives the outbound packets from both the PVM and SVM and compares them
-before allowing the output to be sent to clients.
-
-The SVM is qualified as a valid replica of the PVM, as long as it generates
-identical responses to all client requests. Once the differences in the outputs
-are detected between the PVM and SVM, COLO withholds transmission of the
-outbound packets until it has successfully synchronized the PVM state to the SVM.
-
- Primary Node Secondary Node
-+------------+ +-----------------------+ +------------------------+ +------------+
-| | | HeartBeat +<----->+ HeartBeat | | |
-| Primary VM | +-----------+-----------+ +-----------+------------+ |Secondary VM|
-| | | | | |
-| | +-----------|-----------+ +-----------|------------+ | |
-| | |QEMU +---v----+ | |QEMU +----v---+ | | |
-| | | |Failover| | | |Failover| | | |
-| | | +--------+ | | +--------+ | | |
-| | | +---------------+ | | +---------------+ | | |
-| | | | VM Checkpoint +-------------->+ VM Checkpoint | | | |
-| | | +---------------+ | | +---------------+ | | |
-|Requests<--------------------------\ /-----------------\ /--------------------->Requests|
-| | | ^ ^ | | | | | | |
-|Responses+---------------------\ /-|-|------------\ /-------------------------+Responses|
-| | | | | | | | | | | | | | | |
-| | | +-----------+ | | | | | | | | | | +----------+ | | |
-| | | | COLO disk | | | | | | | | | | | | COLO disk| | | |
-| | | | Manager +---------------------------->| Manager | | | |
-| | | ++----------+ v v | | | | | v v | +---------++ | | |
-| | | |+-----------+-+-+-++| | ++-+--+-+---------+ | | | |
-| | | || COLO Proxy || | | COLO Proxy | | | | |
-| | | || (compare packet || | |(adjust sequence | | | | |
-| | | ||and mirror packet)|| | | and ACK) | | | | |
-| | | |+------------+---+-+| | +-----------------+ | | | |
-+------------+ +-----------------------+ +------------------------+ +------------+
-+------------+ | | | | +------------+
-| VM Monitor | | | | | | VM Monitor |
-+------------+ | | | | +------------+
-+---------------------------------------+ +----------------------------------------+
-| Kernel | | | | | Kernel | |
-+---------------------------------------+ +----------------------------------------+
- | | | |
- +--------------v+ +---------v---+--+ +------------------+ +v-------------+
- | Storage | |External Network| | External Network | | Storage |
- +---------------+ +----------------+ +------------------+ +--------------+
-
-
-== Components introduction ==
-
-You can see there are several components in COLO's diagram of architecture.
-Their functions are described below.
-
-HeartBeat:
-Runs on both the primary and secondary nodes, to periodically check platform
-availability. When the primary node suffers a hardware fail-stop failure,
-the heartbeat stops responding, the secondary node will trigger a failover
-as soon as it determines the absence.
-
-COLO disk Manager:
-When primary VM writes data into image, the colo disk manager captures this data
-and sends it to secondary VM's which makes sure the context of secondary VM's
-image is consistent with the context of primary VM 's image.
-For more details, please refer to docs/block-replication.txt.
-
-Checkpoint/Failover Controller:
-Modifications of save/restore flow to realize continuous migration,
-to make sure the state of VM in Secondary side is always consistent with VM in
-Primary side.
-
-COLO Proxy:
-Delivers packets to Primary and Secondary, and then compare the responses from
-both side. Then decide whether to start a checkpoint according to some rules.
-Please refer to docs/colo-proxy.txt for more information.
-
-Note:
-HeartBeat has not been implemented yet, so you need to trigger failover process
-by using 'x-colo-lost-heartbeat' command.
-
-== COLO operation status ==
-
-+-----------------+
-| |
-| Start COLO |
-| |
-+--------+--------+
- |
- | Main qmp command:
- | migrate-set-capabilities with x-colo
- | migrate
- |
- v
-+--------+--------+
-| |
-| COLO running |
-| |
-+--------+--------+
- |
- | Main qmp command:
- | x-colo-lost-heartbeat
- | or
- | some error happened
- v
-+--------+--------+
-| | send qmp event:
-| COLO failover | COLO_EXIT
-| |
-+-----------------+
-
-COLO use the qmp command to switch and report operation status.
-The diagram just shows the main qmp command, you can get the detail
-in test procedure.
-
-== Test procedure ==
-Note: Here we are running both instances on the same host for testing,
-change the IP Addresses if you want to run it on two hosts. Initially
-127.0.0.1 is the Primary Host and 127.0.0.2 is the Secondary Host.
-
-== Startup qemu ==
-1. Primary:
-Note: Initially, $imagefolder/primary.qcow2 needs to be copied to all hosts.
-You don't need to change any IP's here, because 0.0.0.0 listens on any
-interface. The chardev's with 127.0.0.1 IP's loopback to the local qemu
-instance.
-
-# imagefolder="/mnt/vms/colo-test-primary"
-
-# qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \
- -device piix3-usb-uhci -device usb-tablet -name primary \
- -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \
- -device rtl8139,id=e0,netdev=hn0 \
- -chardev socket,id=mirror0,host=0.0.0.0,port=9003,server=on,wait=off \
- -chardev socket,id=compare1,host=0.0.0.0,port=9004,server=on,wait=on \
- -chardev socket,id=compare0,host=127.0.0.1,port=9001,server=on,wait=off \
- -chardev socket,id=compare0-0,host=127.0.0.1,port=9001 \
- -chardev socket,id=compare_out,host=127.0.0.1,port=9005,server=on,wait=off \
- -chardev socket,id=compare_out0,host=127.0.0.1,port=9005 \
- -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \
- -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out \
- -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \
- -object iothread,id=iothread1 \
- -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,\
-outdev=compare_out0,iothread=iothread1 \
- -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
-children.0.file.filename=$imagefolder/primary.qcow2,children.0.driver=qcow2 -S
-
-2. Secondary:
-Note: Active and hidden images need to be created only once and the
-size should be the same as primary.qcow2. Again, you don't need to change
-any IP's here, except for the $primary_ip variable.
-
-# imagefolder="/mnt/vms/colo-test-secondary"
-# primary_ip=127.0.0.1
-
-# qemu-img create -f qcow2 $imagefolder/secondary-active.qcow2 10G
-
-# qemu-img create -f qcow2 $imagefolder/secondary-hidden.qcow2 10G
-
-# qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \
- -device piix3-usb-uhci -device usb-tablet -name secondary \
- -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \
- -device rtl8139,id=e0,netdev=hn0 \
- -chardev socket,id=red0,host=$primary_ip,port=9003,reconnect-ms=1000 \
- -chardev socket,id=red1,host=$primary_ip,port=9004,reconnect-ms=1000 \
- -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \
- -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \
- -object filter-rewriter,id=rew0,netdev=hn0,queue=all \
- -drive if=none,id=parent0,file.filename=$imagefolder/primary.qcow2,driver=qcow2 \
- -drive if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,\
-top-id=colo-disk0,file.file.filename=$imagefolder/secondary-active.qcow2,\
-file.backing.driver=qcow2,file.backing.file.filename=$imagefolder/secondary-hidden.qcow2,\
-file.backing.backing=parent0 \
- -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
-children.0=childs0 \
- -incoming tcp:0.0.0.0:9998
-
-
-3. On Secondary VM's QEMU monitor, issue command
-{"execute":"qmp_capabilities"}
-{"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }
-{"execute": "nbd-server-start", "arguments": {"addr": {"type": "inet", "data": {"host": "0.0.0.0", "port": "9999"} } } }
-{"execute": "nbd-server-add", "arguments": {"device": "parent0", "writable": true } }
-
-Note:
- a. The qmp command nbd-server-start and nbd-server-add must be run
- before running the qmp command migrate on primary QEMU
- b. Active disk, hidden disk and nbd target's length should be the
- same.
- c. It is better to put active disk and hidden disk in ramdisk. They
- will be merged into the parent disk on failover.
-
-4. On Primary VM's QEMU monitor, issue command:
-{"execute":"qmp_capabilities"}
-{"execute": "human-monitor-command", "arguments": {"command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}}
-{"execute": "x-blockdev-change", "arguments":{"parent": "colo-disk0", "node": "replication0" } }
-{"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }
-{"execute": "migrate", "arguments": {"uri": "tcp:127.0.0.2:9998" } }
-
- Note:
- a. There should be only one NBD Client for each primary disk.
- b. The qmp command line must be run after running qmp command line in
- secondary qemu.
-
-5. After the above steps, you will see, whenever you make changes to PVM, SVM will be synced.
-You can issue command '{ "execute": "migrate-set-parameters" , "arguments":{ "x-checkpoint-delay": 2000 } }'
-to change the idle checkpoint period time
-
-6. Failover test
-You can kill one of the VMs and Failover on the surviving VM:
-
-If you killed the Secondary, then follow "Primary Failover". After that,
-if you want to resume the replication, follow "Primary resume replication"
-
-If you killed the Primary, then follow "Secondary Failover". After that,
-if you want to resume the replication, follow "Secondary resume replication"
-
-== Primary Failover ==
-The Secondary died, resume on the Primary
-
-{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "child": "children.1"} }
-{"execute": "human-monitor-command", "arguments":{ "command-line": "drive_del replication0" } }
-{"execute": "object-del", "arguments":{ "id": "comp0" } }
-{"execute": "object-del", "arguments":{ "id": "iothread1" } }
-{"execute": "object-del", "arguments":{ "id": "m0" } }
-{"execute": "object-del", "arguments":{ "id": "redire0" } }
-{"execute": "object-del", "arguments":{ "id": "redire1" } }
-{"execute": "x-colo-lost-heartbeat" }
-
-== Secondary Failover ==
-The Primary died, resume on the Secondary and prepare to become the new Primary
-
-{"execute": "nbd-server-stop"}
-{"execute": "x-colo-lost-heartbeat"}
-
-{"execute": "object-del", "arguments":{ "id": "f2" } }
-{"execute": "object-del", "arguments":{ "id": "f1" } }
-{"execute": "chardev-remove", "arguments":{ "id": "red1" } }
-{"execute": "chardev-remove", "arguments":{ "id": "red0" } }
-
-{"execute": "chardev-add", "arguments":{ "id": "mirror0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9003" } }, "server": true } } } }
-{"execute": "chardev-add", "arguments":{ "id": "compare1", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9004" } }, "server": true } } } }
-{"execute": "chardev-add", "arguments":{ "id": "compare0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": true } } } }
-{"execute": "chardev-add", "arguments":{ "id": "compare0-0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": false } } } }
-{"execute": "chardev-add", "arguments":{ "id": "compare_out", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": true } } } }
-{"execute": "chardev-add", "arguments":{ "id": "compare_out0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": false } } } }
-
-== Primary resume replication ==
-Resume replication after new Secondary is up.
-
-Start the new Secondary (Steps 2 and 3 above), then on the Primary:
-{"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.2:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }
-
-Wait until disk is synced, then:
-{"execute": "stop"}
-{"execute": "block-job-cancel", "arguments":{ "device": "resync"} }
-
-{"execute": "human-monitor-command", "arguments":{ "command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}}
-{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }
-
-{"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }
-{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }
-{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }
-{"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }
-{"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }
-
-{"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }
-{"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.2:9998" } }
-
-Note:
-If this Primary previously was a Secondary, then we need to insert the
-filters before the filter-rewriter by using the
-""insert": "before", "position": "id=rew0"" Options. See below.
-
-== Secondary resume replication ==
-Become Primary and resume replication after new Secondary is up. Note
-that now 127.0.0.1 is the Secondary and 127.0.0.2 is the Primary.
-
-Start the new Secondary (Steps 2 and 3 above, but with primary_ip=127.0.0.2),
-then on the old Secondary:
-{"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.1:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }
-
-Wait until disk is synced, then:
-{"execute": "stop"}
-{"execute": "block-job-cancel", "arguments":{ "device": "resync" } }
-
-{"execute": "human-monitor-command", "arguments":{ "command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.1,file.port=9999,file.export=parent0,node-name=replication0"}}
-{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }
-
-{"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }
-{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }
-{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }
-{"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }
-{"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }
-
-{"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }
-{"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.1:9998" } }
-
-== TODO ==
-1. Support shared storage.
-2. Develop the heartbeat part.
-3. Reduce checkpoint VM’s downtime while doing checkpoint.
diff --git a/docs/system/index.rst b/docs/system/index.rst
index 427b020483104f6589878bbf255a367ae114c61b..6268c41aea9c74dc3e59d896b5ae082360bfbb1a 100644
--- a/docs/system/index.rst
+++ b/docs/system/index.rst
@@ -41,3 +41,4 @@ or Hypervisor.Framework.
igvm
vm-templating
sriov
+ qemu-colo
diff --git a/docs/system/qemu-colo.rst b/docs/system/qemu-colo.rst
new file mode 100644
index 0000000000000000000000000000000000000000..4b5fbbf398f8a5c4ea6baad615bde94b2b4678d2
--- /dev/null
+++ b/docs/system/qemu-colo.rst
@@ -0,0 +1,360 @@
+Qemu COLO Fault Tolerance
+=========================
+
+| Copyright (c) 2016 Intel Corporation
+| Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
+| Copyright (c) 2016 Fujitsu, Corp.
+
+This work is licensed under the terms of the GNU GPL, version 2 or later.
+See the COPYING file in the top-level directory.
+
+This document gives an overview of COLO's design and how to use it.
+
+Background
+----------
+Virtual machine (VM) replication is a well known technique for providing
+application-agnostic software-implemented hardware fault tolerance,
+also known as "non-stop service".
+
+COLO (COarse-grained LOck-stepping) is a high availability solution.
+Both primary VM (PVM) and secondary VM (SVM) run in parallel. They receive the
+same request from client, and generate response in parallel too.
+If the response packets from PVM and SVM are identical, they are released
+immediately. Otherwise, a VM checkpoint (on demand) is conducted.
+
+Architecture
+------------
+The architecture of COLO is shown in the diagram below.
+It consists of a pair of networked physical nodes:
+The primary node running the PVM, and the secondary node running the SVM
+to maintain a valid replica of the PVM.
+PVM and SVM execute in parallel and generate output of response packets for
+client requests according to the application semantics.
+
+The incoming packets from the client or external network are received by the
+primary node, and then forwarded to the secondary node, so that both the PVM
+and the SVM are stimulated with the same requests.
+
+COLO receives the outbound packets from both the PVM and SVM and compares them
+before allowing the output to be sent to clients.
+
+The SVM is qualified as a valid replica of the PVM, as long as it generates
+identical responses to all client requests. Once the differences in the outputs
+are detected between the PVM and SVM, COLO withholds transmission of the
+outbound packets until it has successfully synchronized the PVM state to the SVM.
+
+Overview::
+
+ Primary Node Secondary Node
+ +------------+ +-----------------------+ +------------------------+ +------------+
+ | | | HeartBeat +<----->+ HeartBeat | | |
+ | Primary VM | +-----------+-----------+ +-----------+------------+ |Secondary VM|
+ | | | | | |
+ | | +-----------|-----------+ +-----------|------------+ | |
+ | | |QEMU +---v----+ | |QEMU +----v---+ | | |
+ | | | |Failover| | | |Failover| | | |
+ | | | +--------+ | | +--------+ | | |
+ | | | +---------------+ | | +---------------+ | | |
+ | | | | VM Checkpoint +-------------->+ VM Checkpoint | | | |
+ | | | +---------------+ | | +---------------+ | | |
+ |Requests<--------------------------\ /-----------------\ /--------------------->Requests|
+ | | | ^ ^ | | | | | | |
+ |Responses+---------------------\ /-|-|------------\ /-------------------------+Responses|
+ | | | | | | | | | | | | | | | |
+ | | | +-----------+ | | | | | | | | | | +----------+ | | |
+ | | | | COLO disk | | | | | | | | | | | | COLO disk| | | |
+ | | | | Manager +---------------------------->| Manager | | | |
+ | | | ++----------+ v v | | | | | v v | +---------++ | | |
+ | | | |+-----------+-+-+-++| | ++-+--+-+---------+ | | | |
+ | | | || COLO Proxy || | | COLO Proxy | | | | |
+ | | | || (compare packet || | |(adjust sequence | | | | |
+ | | | ||and mirror packet)|| | | and ACK) | | | | |
+ | | | |+------------+---+-+| | +-----------------+ | | | |
+ +------------+ +-----------------------+ +------------------------+ +------------+
+ +------------+ | | | | +------------+
+ | VM Monitor | | | | | | VM Monitor |
+ +------------+ | | | | +------------+
+ +---------------------------------------+ +----------------------------------------+
+ | Kernel | | | | | Kernel | |
+ +---------------------------------------+ +----------------------------------------+
+ | | | |
+ +--------------v+ +---------v---+--+ +------------------+ +v-------------+
+ | Storage | |External Network| | External Network | | Storage |
+ +---------------+ +----------------+ +------------------+ +--------------+
+
+Components introduction
+^^^^^^^^^^^^^^^^^^^^^^^
+You can see there are several components in COLO's diagram of architecture.
+Their functions are described below.
+
+HeartBeat
+~~~~~~~~~
+Runs on both the primary and secondary nodes, to periodically check platform
+availability. When the primary node suffers a hardware fail-stop failure,
+the heartbeat stops responding, the secondary node will trigger a failover
+as soon as it determines the absence.
+
+COLO disk Manager
+~~~~~~~~~~~~~~~~~
+When primary VM writes data into image, the colo disk manager captures this data
+and sends it to secondary VM's which makes sure the context of secondary VM's
+image is consistent with the context of primary VM 's image.
+For more details, please refer to docs/block-replication.txt.
+
+Checkpoint/Failover Controller
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Modifications of save/restore flow to realize continuous migration,
+to make sure the state of VM in Secondary side is always consistent with VM in
+Primary side.
+
+COLO Proxy
+~~~~~~~~~~
+Delivers packets to Primary and Secondary, and then compare the responses from
+both side. Then decide whether to start a checkpoint according to some rules.
+Please refer to docs/colo-proxy.txt for more information.
+
+Note:
+HeartBeat has not been implemented yet, so you need to trigger failover process
+by using 'x-colo-lost-heartbeat' command.
+
+COLO operation status
+^^^^^^^^^^^^^^^^^^^^^
+
+Overview::
+
+ +-----------------+
+ | |
+ | Start COLO |
+ | |
+ +--------+--------+
+ |
+ | Main qmp command:
+ | migrate-set-capabilities with x-colo
+ | migrate
+ |
+ v
+ +--------+--------+
+ | |
+ | COLO running |
+ | |
+ +--------+--------+
+ |
+ | Main qmp command:
+ | x-colo-lost-heartbeat
+ | or
+ | some error happened
+ v
+ +--------+--------+
+ | | send qmp event:
+ | COLO failover | COLO_EXIT
+ | |
+ +-----------------+
+
+
+COLO use the qmp command to switch and report operation status.
+The diagram just shows the main qmp command, you can get the detail
+in test procedure.
+
+Test procedure
+--------------
+Note: Here we are running both instances on the same host for testing,
+change the IP Addresses if you want to run it on two hosts. Initially
+``127.0.0.1`` is the Primary Host and ``127.0.0.2`` is the Secondary Host.
+
+Startup qemu
+^^^^^^^^^^^^
+**1. Primary**:
+Note: Initially, ``$imagefolder/primary.qcow2`` needs to be copied to all hosts.
+You don't need to change any IP's here, because ``0.0.0.0`` listens on any
+interface. The chardev's with ``127.0.0.1`` IP's loopback to the local qemu
+instance::
+
+ # imagefolder="/mnt/vms/colo-test-primary"
+
+ # qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \
+ -device piix3-usb-uhci -device usb-tablet -name primary \
+ -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \
+ -device rtl8139,id=e0,netdev=hn0 \
+ -chardev socket,id=mirror0,host=0.0.0.0,port=9003,server=on,wait=off \
+ -chardev socket,id=compare1,host=0.0.0.0,port=9004,server=on,wait=on \
+ -chardev socket,id=compare0,host=127.0.0.1,port=9001,server=on,wait=off \
+ -chardev socket,id=compare0-0,host=127.0.0.1,port=9001 \
+ -chardev socket,id=compare_out,host=127.0.0.1,port=9005,server=on,wait=off \
+ -chardev socket,id=compare_out0,host=127.0.0.1,port=9005 \
+ -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \
+ -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out \
+ -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \
+ -object iothread,id=iothread1 \
+ -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,\
+ outdev=compare_out0,iothread=iothread1 \
+ -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
+ children.0.file.filename=$imagefolder/primary.qcow2,children.0.driver=qcow2 -S
+
+
+**2. Secondary**:
+Note: Active and hidden images need to be created only once and the
+size should be the same as ``primary.qcow2``. Again, you don't need to change
+any IP's here, except for the ``$primary_ip`` variable::
+
+ # imagefolder="/mnt/vms/colo-test-secondary"
+ # primary_ip=127.0.0.1
+
+ # qemu-img create -f qcow2 $imagefolder/secondary-active.qcow2 10G
+
+ # qemu-img create -f qcow2 $imagefolder/secondary-hidden.qcow2 10G
+
+ # qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \
+ -device piix3-usb-uhci -device usb-tablet -name secondary \
+ -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \
+ -device rtl8139,id=e0,netdev=hn0 \
+ -chardev socket,id=red0,host=$primary_ip,port=9003,reconnect-ms=1000 \
+ -chardev socket,id=red1,host=$primary_ip,port=9004,reconnect-ms=1000 \
+ -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \
+ -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \
+ -object filter-rewriter,id=rew0,netdev=hn0,queue=all \
+ -drive if=none,id=parent0,file.filename=$imagefolder/primary.qcow2,driver=qcow2 \
+ -drive if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,\
+ top-id=colo-disk0,file.file.filename=$imagefolder/secondary-active.qcow2,\
+ file.backing.driver=qcow2,file.backing.file.filename=$imagefolder/secondary-hidden.qcow2,\
+ file.backing.backing=parent0 \
+ -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
+ children.0=childs0 \
+ -incoming tcp:0.0.0.0:9998
+
+
+**3.** On Secondary VM's QEMU monitor, issue command::
+
+ {"execute":"qmp_capabilities"}
+ {"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }
+ {"execute": "nbd-server-start", "arguments": {"addr": {"type": "inet", "data": {"host": "0.0.0.0", "port": "9999"} } } }
+ {"execute": "nbd-server-add", "arguments": {"device": "parent0", "writable": true } }
+
+Note:
+ a. The qmp command ``nbd-server-start`` and ``nbd-server-add`` must be run
+ before running the qmp command migrate on primary QEMU
+ b. Active disk, hidden disk and nbd target's length should be the
+ same.
+ c. It is better to put active disk and hidden disk in ramdisk. They
+ will be merged into the parent disk on failover.
+
+**4.** On Primary VM's QEMU monitor, issue command::
+
+ {"execute":"qmp_capabilities"}
+ {"execute": "human-monitor-command", "arguments": {"command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}}
+ {"execute": "x-blockdev-change", "arguments":{"parent": "colo-disk0", "node": "replication0" } }
+ {"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }
+ {"execute": "migrate", "arguments": {"uri": "tcp:127.0.0.2:9998" } }
+
+Note:
+ a. There should be only one NBD Client for each primary disk.
+ b. The qmp command line must be run after running qmp command line in
+ secondary qemu.
+
+**5.** After the above steps, you will see, whenever you make changes to PVM, SVM will be synced.
+You can issue command ``{ "execute": "migrate-set-parameters" , "arguments":{ "x-checkpoint-delay": 2000 } }``
+to change the idle checkpoint period time
+
+Failover test
+^^^^^^^^^^^^^
+You can kill one of the VMs and Failover on the surviving VM:
+
+If you killed the Secondary, then follow "Primary Failover".
+After that, if you want to resume the replication, follow "Primary resume replication"
+
+If you killed the Primary, then follow "Secondary Failover".
+After that, if you want to resume the replication, follow "Secondary resume replication"
+
+Primary Failover
+~~~~~~~~~~~~~~~~
+The Secondary died, resume on the Primary::
+
+ {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "child": "children.1"} }
+ {"execute": "human-monitor-command", "arguments":{ "command-line": "drive_del replication0" } }
+ {"execute": "object-del", "arguments":{ "id": "comp0" } }
+ {"execute": "object-del", "arguments":{ "id": "iothread1" } }
+ {"execute": "object-del", "arguments":{ "id": "m0" } }
+ {"execute": "object-del", "arguments":{ "id": "redire0" } }
+ {"execute": "object-del", "arguments":{ "id": "redire1" } }
+ {"execute": "x-colo-lost-heartbeat" }
+
+Secondary Failover
+~~~~~~~~~~~~~~~~~~
+The Primary died, resume on the Secondary and prepare to become the new Primary::
+
+ {"execute": "nbd-server-stop"}
+ {"execute": "x-colo-lost-heartbeat"}
+
+ {"execute": "object-del", "arguments":{ "id": "f2" } }
+ {"execute": "object-del", "arguments":{ "id": "f1" } }
+ {"execute": "chardev-remove", "arguments":{ "id": "red1" } }
+ {"execute": "chardev-remove", "arguments":{ "id": "red0" } }
+
+ {"execute": "chardev-add", "arguments":{ "id": "mirror0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9003" } }, "server": true } } } }
+ {"execute": "chardev-add", "arguments":{ "id": "compare1", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9004" } }, "server": true } } } }
+ {"execute": "chardev-add", "arguments":{ "id": "compare0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": true } } } }
+ {"execute": "chardev-add", "arguments":{ "id": "compare0-0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": false } } } }
+ {"execute": "chardev-add", "arguments":{ "id": "compare_out", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": true } } } }
+ {"execute": "chardev-add", "arguments":{ "id": "compare_out0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": false } } } }
+
+Primary resume replication
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+Resume replication after new Secondary is up.
+
+Start the new Secondary (Steps 2 and 3 above), then on the Primary::
+
+ {"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.2:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }
+
+Wait until disk is synced, then::
+
+ {"execute": "stop"}
+ {"execute": "block-job-cancel", "arguments":{ "device": "resync"} }
+
+ {"execute": "human-monitor-command", "arguments":{ "command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}}
+ {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }
+
+ {"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }
+ {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }
+ {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }
+ {"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }
+ {"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }
+
+ {"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }
+ {"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.2:9998" } }
+
+Note:
+If this Primary previously was a Secondary, then we need to insert the
+filters before the filter-rewriter by using the
+""insert": "before", "position": "id=rew0"" Options. See below.
+
+Secondary resume replication
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Become Primary and resume replication after new Secondary is up. Note
+that now 127.0.0.1 is the Secondary and 127.0.0.2 is the Primary.
+
+Start the new Secondary (Steps 2 and 3 above, but with primary_ip=127.0.0.2),
+then on the old Secondary::
+
+ {"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.1:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }
+
+Wait until disk is synced, then::
+
+ {"execute": "stop"}
+ {"execute": "block-job-cancel", "arguments":{ "device": "resync" } }
+
+ {"execute": "human-monitor-command", "arguments":{ "command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.1,file.port=9999,file.export=parent0,node-name=replication0"}}
+ {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }
+
+ {"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }
+ {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }
+ {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }
+ {"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }
+ {"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }
+
+ {"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }
+ {"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.1:9998" } }
+
+TODO
+----
+1. Support shared storage.
+2. Develop the heartbeat part.
+3. Reduce checkpoint VM’s downtime while doing checkpoint.
--
2.39.5On Tue, Feb 3, 2026 at 6:15 PM Lukas Straub <lukasstraub2@web.de> wrote:
>
> Reviewed-by: Fabiano Rosas <farosas@suse.de>
> Signed-off-by: Lukas Straub <lukasstraub2@web.de>
Reviewed-by: Zhang Chen <zhangckid@gmail.com>
Thanks
Chen
> ---
> MAINTAINERS | 2 +-
> docs/COLO-FT.txt | 334 ------------------------------------------
> docs/system/index.rst | 1 +
> docs/system/qemu-colo.rst | 360 ++++++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 362 insertions(+), 335 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8e63e0a08fc7417036986f27c2d910eb99d8a96a..f645590b8b940919bdc84ad585ee493f5452fc20 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3855,7 +3855,7 @@ F: migration/multifd-colo.*
> F: include/migration/colo.h
> F: include/migration/failover.h
> F: tests/qtest/migration/colo-tests.c
> -F: docs/COLO-FT.txt
> +F: docs/system/qemu-colo.rst
>
> COLO Proxy
> M: Zhang Chen <zhangckid@gmail.com>
> diff --git a/docs/COLO-FT.txt b/docs/COLO-FT.txt
> deleted file mode 100644
> index 2283a09c080b8996f9767eeb415e8d4fbdc940af..0000000000000000000000000000000000000000
> --- a/docs/COLO-FT.txt
> +++ /dev/null
> @@ -1,334 +0,0 @@
> -COarse-grained LOck-stepping Virtual Machines for Non-stop Service
> -----------------------------------------
> -Copyright (c) 2016 Intel Corporation
> -Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
> -Copyright (c) 2016 Fujitsu, Corp.
> -
> -This work is licensed under the terms of the GNU GPL, version 2 or later.
> -See the COPYING file in the top-level directory.
> -
> -This document gives an overview of COLO's design and how to use it.
> -
> -== Background ==
> -Virtual machine (VM) replication is a well known technique for providing
> -application-agnostic software-implemented hardware fault tolerance,
> -also known as "non-stop service".
> -
> -COLO (COarse-grained LOck-stepping) is a high availability solution.
> -Both primary VM (PVM) and secondary VM (SVM) run in parallel. They receive the
> -same request from client, and generate response in parallel too.
> -If the response packets from PVM and SVM are identical, they are released
> -immediately. Otherwise, a VM checkpoint (on demand) is conducted.
> -
> -== Architecture ==
> -
> -The architecture of COLO is shown in the diagram below.
> -It consists of a pair of networked physical nodes:
> -The primary node running the PVM, and the secondary node running the SVM
> -to maintain a valid replica of the PVM.
> -PVM and SVM execute in parallel and generate output of response packets for
> -client requests according to the application semantics.
> -
> -The incoming packets from the client or external network are received by the
> -primary node, and then forwarded to the secondary node, so that both the PVM
> -and the SVM are stimulated with the same requests.
> -
> -COLO receives the outbound packets from both the PVM and SVM and compares them
> -before allowing the output to be sent to clients.
> -
> -The SVM is qualified as a valid replica of the PVM, as long as it generates
> -identical responses to all client requests. Once the differences in the outputs
> -are detected between the PVM and SVM, COLO withholds transmission of the
> -outbound packets until it has successfully synchronized the PVM state to the SVM.
> -
> - Primary Node Secondary Node
> -+------------+ +-----------------------+ +------------------------+ +------------+
> -| | | HeartBeat +<----->+ HeartBeat | | |
> -| Primary VM | +-----------+-----------+ +-----------+------------+ |Secondary VM|
> -| | | | | |
> -| | +-----------|-----------+ +-----------|------------+ | |
> -| | |QEMU +---v----+ | |QEMU +----v---+ | | |
> -| | | |Failover| | | |Failover| | | |
> -| | | +--------+ | | +--------+ | | |
> -| | | +---------------+ | | +---------------+ | | |
> -| | | | VM Checkpoint +-------------->+ VM Checkpoint | | | |
> -| | | +---------------+ | | +---------------+ | | |
> -|Requests<--------------------------\ /-----------------\ /--------------------->Requests|
> -| | | ^ ^ | | | | | | |
> -|Responses+---------------------\ /-|-|------------\ /-------------------------+Responses|
> -| | | | | | | | | | | | | | | |
> -| | | +-----------+ | | | | | | | | | | +----------+ | | |
> -| | | | COLO disk | | | | | | | | | | | | COLO disk| | | |
> -| | | | Manager +---------------------------->| Manager | | | |
> -| | | ++----------+ v v | | | | | v v | +---------++ | | |
> -| | | |+-----------+-+-+-++| | ++-+--+-+---------+ | | | |
> -| | | || COLO Proxy || | | COLO Proxy | | | | |
> -| | | || (compare packet || | |(adjust sequence | | | | |
> -| | | ||and mirror packet)|| | | and ACK) | | | | |
> -| | | |+------------+---+-+| | +-----------------+ | | | |
> -+------------+ +-----------------------+ +------------------------+ +------------+
> -+------------+ | | | | +------------+
> -| VM Monitor | | | | | | VM Monitor |
> -+------------+ | | | | +------------+
> -+---------------------------------------+ +----------------------------------------+
> -| Kernel | | | | | Kernel | |
> -+---------------------------------------+ +----------------------------------------+
> - | | | |
> - +--------------v+ +---------v---+--+ +------------------+ +v-------------+
> - | Storage | |External Network| | External Network | | Storage |
> - +---------------+ +----------------+ +------------------+ +--------------+
> -
> -
> -== Components introduction ==
> -
> -You can see there are several components in COLO's diagram of architecture.
> -Their functions are described below.
> -
> -HeartBeat:
> -Runs on both the primary and secondary nodes, to periodically check platform
> -availability. When the primary node suffers a hardware fail-stop failure,
> -the heartbeat stops responding, the secondary node will trigger a failover
> -as soon as it determines the absence.
> -
> -COLO disk Manager:
> -When primary VM writes data into image, the colo disk manager captures this data
> -and sends it to secondary VM's which makes sure the context of secondary VM's
> -image is consistent with the context of primary VM 's image.
> -For more details, please refer to docs/block-replication.txt.
> -
> -Checkpoint/Failover Controller:
> -Modifications of save/restore flow to realize continuous migration,
> -to make sure the state of VM in Secondary side is always consistent with VM in
> -Primary side.
> -
> -COLO Proxy:
> -Delivers packets to Primary and Secondary, and then compare the responses from
> -both side. Then decide whether to start a checkpoint according to some rules.
> -Please refer to docs/colo-proxy.txt for more information.
> -
> -Note:
> -HeartBeat has not been implemented yet, so you need to trigger failover process
> -by using 'x-colo-lost-heartbeat' command.
> -
> -== COLO operation status ==
> -
> -+-----------------+
> -| |
> -| Start COLO |
> -| |
> -+--------+--------+
> - |
> - | Main qmp command:
> - | migrate-set-capabilities with x-colo
> - | migrate
> - |
> - v
> -+--------+--------+
> -| |
> -| COLO running |
> -| |
> -+--------+--------+
> - |
> - | Main qmp command:
> - | x-colo-lost-heartbeat
> - | or
> - | some error happened
> - v
> -+--------+--------+
> -| | send qmp event:
> -| COLO failover | COLO_EXIT
> -| |
> -+-----------------+
> -
> -COLO use the qmp command to switch and report operation status.
> -The diagram just shows the main qmp command, you can get the detail
> -in test procedure.
> -
> -== Test procedure ==
> -Note: Here we are running both instances on the same host for testing,
> -change the IP Addresses if you want to run it on two hosts. Initially
> -127.0.0.1 is the Primary Host and 127.0.0.2 is the Secondary Host.
> -
> -== Startup qemu ==
> -1. Primary:
> -Note: Initially, $imagefolder/primary.qcow2 needs to be copied to all hosts.
> -You don't need to change any IP's here, because 0.0.0.0 listens on any
> -interface. The chardev's with 127.0.0.1 IP's loopback to the local qemu
> -instance.
> -
> -# imagefolder="/mnt/vms/colo-test-primary"
> -
> -# qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \
> - -device piix3-usb-uhci -device usb-tablet -name primary \
> - -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \
> - -device rtl8139,id=e0,netdev=hn0 \
> - -chardev socket,id=mirror0,host=0.0.0.0,port=9003,server=on,wait=off \
> - -chardev socket,id=compare1,host=0.0.0.0,port=9004,server=on,wait=on \
> - -chardev socket,id=compare0,host=127.0.0.1,port=9001,server=on,wait=off \
> - -chardev socket,id=compare0-0,host=127.0.0.1,port=9001 \
> - -chardev socket,id=compare_out,host=127.0.0.1,port=9005,server=on,wait=off \
> - -chardev socket,id=compare_out0,host=127.0.0.1,port=9005 \
> - -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \
> - -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out \
> - -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \
> - -object iothread,id=iothread1 \
> - -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,\
> -outdev=compare_out0,iothread=iothread1 \
> - -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
> -children.0.file.filename=$imagefolder/primary.qcow2,children.0.driver=qcow2 -S
> -
> -2. Secondary:
> -Note: Active and hidden images need to be created only once and the
> -size should be the same as primary.qcow2. Again, you don't need to change
> -any IP's here, except for the $primary_ip variable.
> -
> -# imagefolder="/mnt/vms/colo-test-secondary"
> -# primary_ip=127.0.0.1
> -
> -# qemu-img create -f qcow2 $imagefolder/secondary-active.qcow2 10G
> -
> -# qemu-img create -f qcow2 $imagefolder/secondary-hidden.qcow2 10G
> -
> -# qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \
> - -device piix3-usb-uhci -device usb-tablet -name secondary \
> - -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \
> - -device rtl8139,id=e0,netdev=hn0 \
> - -chardev socket,id=red0,host=$primary_ip,port=9003,reconnect-ms=1000 \
> - -chardev socket,id=red1,host=$primary_ip,port=9004,reconnect-ms=1000 \
> - -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \
> - -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \
> - -object filter-rewriter,id=rew0,netdev=hn0,queue=all \
> - -drive if=none,id=parent0,file.filename=$imagefolder/primary.qcow2,driver=qcow2 \
> - -drive if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,\
> -top-id=colo-disk0,file.file.filename=$imagefolder/secondary-active.qcow2,\
> -file.backing.driver=qcow2,file.backing.file.filename=$imagefolder/secondary-hidden.qcow2,\
> -file.backing.backing=parent0 \
> - -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
> -children.0=childs0 \
> - -incoming tcp:0.0.0.0:9998
> -
> -
> -3. On Secondary VM's QEMU monitor, issue command
> -{"execute":"qmp_capabilities"}
> -{"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }
> -{"execute": "nbd-server-start", "arguments": {"addr": {"type": "inet", "data": {"host": "0.0.0.0", "port": "9999"} } } }
> -{"execute": "nbd-server-add", "arguments": {"device": "parent0", "writable": true } }
> -
> -Note:
> - a. The qmp command nbd-server-start and nbd-server-add must be run
> - before running the qmp command migrate on primary QEMU
> - b. Active disk, hidden disk and nbd target's length should be the
> - same.
> - c. It is better to put active disk and hidden disk in ramdisk. They
> - will be merged into the parent disk on failover.
> -
> -4. On Primary VM's QEMU monitor, issue command:
> -{"execute":"qmp_capabilities"}
> -{"execute": "human-monitor-command", "arguments": {"command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}}
> -{"execute": "x-blockdev-change", "arguments":{"parent": "colo-disk0", "node": "replication0" } }
> -{"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }
> -{"execute": "migrate", "arguments": {"uri": "tcp:127.0.0.2:9998" } }
> -
> - Note:
> - a. There should be only one NBD Client for each primary disk.
> - b. The qmp command line must be run after running qmp command line in
> - secondary qemu.
> -
> -5. After the above steps, you will see, whenever you make changes to PVM, SVM will be synced.
> -You can issue command '{ "execute": "migrate-set-parameters" , "arguments":{ "x-checkpoint-delay": 2000 } }'
> -to change the idle checkpoint period time
> -
> -6. Failover test
> -You can kill one of the VMs and Failover on the surviving VM:
> -
> -If you killed the Secondary, then follow "Primary Failover". After that,
> -if you want to resume the replication, follow "Primary resume replication"
> -
> -If you killed the Primary, then follow "Secondary Failover". After that,
> -if you want to resume the replication, follow "Secondary resume replication"
> -
> -== Primary Failover ==
> -The Secondary died, resume on the Primary
> -
> -{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "child": "children.1"} }
> -{"execute": "human-monitor-command", "arguments":{ "command-line": "drive_del replication0" } }
> -{"execute": "object-del", "arguments":{ "id": "comp0" } }
> -{"execute": "object-del", "arguments":{ "id": "iothread1" } }
> -{"execute": "object-del", "arguments":{ "id": "m0" } }
> -{"execute": "object-del", "arguments":{ "id": "redire0" } }
> -{"execute": "object-del", "arguments":{ "id": "redire1" } }
> -{"execute": "x-colo-lost-heartbeat" }
> -
> -== Secondary Failover ==
> -The Primary died, resume on the Secondary and prepare to become the new Primary
> -
> -{"execute": "nbd-server-stop"}
> -{"execute": "x-colo-lost-heartbeat"}
> -
> -{"execute": "object-del", "arguments":{ "id": "f2" } }
> -{"execute": "object-del", "arguments":{ "id": "f1" } }
> -{"execute": "chardev-remove", "arguments":{ "id": "red1" } }
> -{"execute": "chardev-remove", "arguments":{ "id": "red0" } }
> -
> -{"execute": "chardev-add", "arguments":{ "id": "mirror0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9003" } }, "server": true } } } }
> -{"execute": "chardev-add", "arguments":{ "id": "compare1", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9004" } }, "server": true } } } }
> -{"execute": "chardev-add", "arguments":{ "id": "compare0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": true } } } }
> -{"execute": "chardev-add", "arguments":{ "id": "compare0-0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": false } } } }
> -{"execute": "chardev-add", "arguments":{ "id": "compare_out", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": true } } } }
> -{"execute": "chardev-add", "arguments":{ "id": "compare_out0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": false } } } }
> -
> -== Primary resume replication ==
> -Resume replication after new Secondary is up.
> -
> -Start the new Secondary (Steps 2 and 3 above), then on the Primary:
> -{"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.2:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }
> -
> -Wait until disk is synced, then:
> -{"execute": "stop"}
> -{"execute": "block-job-cancel", "arguments":{ "device": "resync"} }
> -
> -{"execute": "human-monitor-command", "arguments":{ "command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}}
> -{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }
> -
> -{"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }
> -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }
> -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }
> -{"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }
> -{"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }
> -
> -{"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }
> -{"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.2:9998" } }
> -
> -Note:
> -If this Primary previously was a Secondary, then we need to insert the
> -filters before the filter-rewriter by using the
> -""insert": "before", "position": "id=rew0"" Options. See below.
> -
> -== Secondary resume replication ==
> -Become Primary and resume replication after new Secondary is up. Note
> -that now 127.0.0.1 is the Secondary and 127.0.0.2 is the Primary.
> -
> -Start the new Secondary (Steps 2 and 3 above, but with primary_ip=127.0.0.2),
> -then on the old Secondary:
> -{"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.1:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }
> -
> -Wait until disk is synced, then:
> -{"execute": "stop"}
> -{"execute": "block-job-cancel", "arguments":{ "device": "resync" } }
> -
> -{"execute": "human-monitor-command", "arguments":{ "command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.1,file.port=9999,file.export=parent0,node-name=replication0"}}
> -{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }
> -
> -{"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }
> -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }
> -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }
> -{"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }
> -{"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }
> -
> -{"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }
> -{"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.1:9998" } }
> -
> -== TODO ==
> -1. Support shared storage.
> -2. Develop the heartbeat part.
> -3. Reduce checkpoint VM’s downtime while doing checkpoint.
> diff --git a/docs/system/index.rst b/docs/system/index.rst
> index 427b020483104f6589878bbf255a367ae114c61b..6268c41aea9c74dc3e59d896b5ae082360bfbb1a 100644
> --- a/docs/system/index.rst
> +++ b/docs/system/index.rst
> @@ -41,3 +41,4 @@ or Hypervisor.Framework.
> igvm
> vm-templating
> sriov
> + qemu-colo
> diff --git a/docs/system/qemu-colo.rst b/docs/system/qemu-colo.rst
> new file mode 100644
> index 0000000000000000000000000000000000000000..4b5fbbf398f8a5c4ea6baad615bde94b2b4678d2
> --- /dev/null
> +++ b/docs/system/qemu-colo.rst
> @@ -0,0 +1,360 @@
> +Qemu COLO Fault Tolerance
> +=========================
> +
> +| Copyright (c) 2016 Intel Corporation
> +| Copyright (c) 2016 HUAWEI TECHNOLOGIES CO., LTD.
> +| Copyright (c) 2016 Fujitsu, Corp.
> +
> +This work is licensed under the terms of the GNU GPL, version 2 or later.
> +See the COPYING file in the top-level directory.
> +
> +This document gives an overview of COLO's design and how to use it.
> +
> +Background
> +----------
> +Virtual machine (VM) replication is a well known technique for providing
> +application-agnostic software-implemented hardware fault tolerance,
> +also known as "non-stop service".
> +
> +COLO (COarse-grained LOck-stepping) is a high availability solution.
> +Both primary VM (PVM) and secondary VM (SVM) run in parallel. They receive the
> +same request from client, and generate response in parallel too.
> +If the response packets from PVM and SVM are identical, they are released
> +immediately. Otherwise, a VM checkpoint (on demand) is conducted.
> +
> +Architecture
> +------------
> +The architecture of COLO is shown in the diagram below.
> +It consists of a pair of networked physical nodes:
> +The primary node running the PVM, and the secondary node running the SVM
> +to maintain a valid replica of the PVM.
> +PVM and SVM execute in parallel and generate output of response packets for
> +client requests according to the application semantics.
> +
> +The incoming packets from the client or external network are received by the
> +primary node, and then forwarded to the secondary node, so that both the PVM
> +and the SVM are stimulated with the same requests.
> +
> +COLO receives the outbound packets from both the PVM and SVM and compares them
> +before allowing the output to be sent to clients.
> +
> +The SVM is qualified as a valid replica of the PVM, as long as it generates
> +identical responses to all client requests. Once the differences in the outputs
> +are detected between the PVM and SVM, COLO withholds transmission of the
> +outbound packets until it has successfully synchronized the PVM state to the SVM.
> +
> +Overview::
> +
> + Primary Node Secondary Node
> + +------------+ +-----------------------+ +------------------------+ +------------+
> + | | | HeartBeat +<----->+ HeartBeat | | |
> + | Primary VM | +-----------+-----------+ +-----------+------------+ |Secondary VM|
> + | | | | | |
> + | | +-----------|-----------+ +-----------|------------+ | |
> + | | |QEMU +---v----+ | |QEMU +----v---+ | | |
> + | | | |Failover| | | |Failover| | | |
> + | | | +--------+ | | +--------+ | | |
> + | | | +---------------+ | | +---------------+ | | |
> + | | | | VM Checkpoint +-------------->+ VM Checkpoint | | | |
> + | | | +---------------+ | | +---------------+ | | |
> + |Requests<--------------------------\ /-----------------\ /--------------------->Requests|
> + | | | ^ ^ | | | | | | |
> + |Responses+---------------------\ /-|-|------------\ /-------------------------+Responses|
> + | | | | | | | | | | | | | | | |
> + | | | +-----------+ | | | | | | | | | | +----------+ | | |
> + | | | | COLO disk | | | | | | | | | | | | COLO disk| | | |
> + | | | | Manager +---------------------------->| Manager | | | |
> + | | | ++----------+ v v | | | | | v v | +---------++ | | |
> + | | | |+-----------+-+-+-++| | ++-+--+-+---------+ | | | |
> + | | | || COLO Proxy || | | COLO Proxy | | | | |
> + | | | || (compare packet || | |(adjust sequence | | | | |
> + | | | ||and mirror packet)|| | | and ACK) | | | | |
> + | | | |+------------+---+-+| | +-----------------+ | | | |
> + +------------+ +-----------------------+ +------------------------+ +------------+
> + +------------+ | | | | +------------+
> + | VM Monitor | | | | | | VM Monitor |
> + +------------+ | | | | +------------+
> + +---------------------------------------+ +----------------------------------------+
> + | Kernel | | | | | Kernel | |
> + +---------------------------------------+ +----------------------------------------+
> + | | | |
> + +--------------v+ +---------v---+--+ +------------------+ +v-------------+
> + | Storage | |External Network| | External Network | | Storage |
> + +---------------+ +----------------+ +------------------+ +--------------+
> +
> +Components introduction
> +^^^^^^^^^^^^^^^^^^^^^^^
> +You can see there are several components in COLO's diagram of architecture.
> +Their functions are described below.
> +
> +HeartBeat
> +~~~~~~~~~
> +Runs on both the primary and secondary nodes, to periodically check platform
> +availability. When the primary node suffers a hardware fail-stop failure,
> +the heartbeat stops responding, the secondary node will trigger a failover
> +as soon as it determines the absence.
> +
> +COLO disk Manager
> +~~~~~~~~~~~~~~~~~
> +When primary VM writes data into image, the colo disk manager captures this data
> +and sends it to secondary VM's which makes sure the context of secondary VM's
> +image is consistent with the context of primary VM 's image.
> +For more details, please refer to docs/block-replication.txt.
> +
> +Checkpoint/Failover Controller
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +Modifications of save/restore flow to realize continuous migration,
> +to make sure the state of VM in Secondary side is always consistent with VM in
> +Primary side.
> +
> +COLO Proxy
> +~~~~~~~~~~
> +Delivers packets to Primary and Secondary, and then compare the responses from
> +both side. Then decide whether to start a checkpoint according to some rules.
> +Please refer to docs/colo-proxy.txt for more information.
> +
> +Note:
> +HeartBeat has not been implemented yet, so you need to trigger failover process
> +by using 'x-colo-lost-heartbeat' command.
> +
> +COLO operation status
> +^^^^^^^^^^^^^^^^^^^^^
> +
> +Overview::
> +
> + +-----------------+
> + | |
> + | Start COLO |
> + | |
> + +--------+--------+
> + |
> + | Main qmp command:
> + | migrate-set-capabilities with x-colo
> + | migrate
> + |
> + v
> + +--------+--------+
> + | |
> + | COLO running |
> + | |
> + +--------+--------+
> + |
> + | Main qmp command:
> + | x-colo-lost-heartbeat
> + | or
> + | some error happened
> + v
> + +--------+--------+
> + | | send qmp event:
> + | COLO failover | COLO_EXIT
> + | |
> + +-----------------+
> +
> +
> +COLO use the qmp command to switch and report operation status.
> +The diagram just shows the main qmp command, you can get the detail
> +in test procedure.
> +
> +Test procedure
> +--------------
> +Note: Here we are running both instances on the same host for testing,
> +change the IP Addresses if you want to run it on two hosts. Initially
> +``127.0.0.1`` is the Primary Host and ``127.0.0.2`` is the Secondary Host.
> +
> +Startup qemu
> +^^^^^^^^^^^^
> +**1. Primary**:
> +Note: Initially, ``$imagefolder/primary.qcow2`` needs to be copied to all hosts.
> +You don't need to change any IP's here, because ``0.0.0.0`` listens on any
> +interface. The chardev's with ``127.0.0.1`` IP's loopback to the local qemu
> +instance::
> +
> + # imagefolder="/mnt/vms/colo-test-primary"
> +
> + # qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \
> + -device piix3-usb-uhci -device usb-tablet -name primary \
> + -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \
> + -device rtl8139,id=e0,netdev=hn0 \
> + -chardev socket,id=mirror0,host=0.0.0.0,port=9003,server=on,wait=off \
> + -chardev socket,id=compare1,host=0.0.0.0,port=9004,server=on,wait=on \
> + -chardev socket,id=compare0,host=127.0.0.1,port=9001,server=on,wait=off \
> + -chardev socket,id=compare0-0,host=127.0.0.1,port=9001 \
> + -chardev socket,id=compare_out,host=127.0.0.1,port=9005,server=on,wait=off \
> + -chardev socket,id=compare_out0,host=127.0.0.1,port=9005 \
> + -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \
> + -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out \
> + -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \
> + -object iothread,id=iothread1 \
> + -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,\
> + outdev=compare_out0,iothread=iothread1 \
> + -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
> + children.0.file.filename=$imagefolder/primary.qcow2,children.0.driver=qcow2 -S
> +
> +
> +**2. Secondary**:
> +Note: Active and hidden images need to be created only once and the
> +size should be the same as ``primary.qcow2``. Again, you don't need to change
> +any IP's here, except for the ``$primary_ip`` variable::
> +
> + # imagefolder="/mnt/vms/colo-test-secondary"
> + # primary_ip=127.0.0.1
> +
> + # qemu-img create -f qcow2 $imagefolder/secondary-active.qcow2 10G
> +
> + # qemu-img create -f qcow2 $imagefolder/secondary-hidden.qcow2 10G
> +
> + # qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \
> + -device piix3-usb-uhci -device usb-tablet -name secondary \
> + -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \
> + -device rtl8139,id=e0,netdev=hn0 \
> + -chardev socket,id=red0,host=$primary_ip,port=9003,reconnect-ms=1000 \
> + -chardev socket,id=red1,host=$primary_ip,port=9004,reconnect-ms=1000 \
> + -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \
> + -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \
> + -object filter-rewriter,id=rew0,netdev=hn0,queue=all \
> + -drive if=none,id=parent0,file.filename=$imagefolder/primary.qcow2,driver=qcow2 \
> + -drive if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,\
> + top-id=colo-disk0,file.file.filename=$imagefolder/secondary-active.qcow2,\
> + file.backing.driver=qcow2,file.backing.file.filename=$imagefolder/secondary-hidden.qcow2,\
> + file.backing.backing=parent0 \
> + -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
> + children.0=childs0 \
> + -incoming tcp:0.0.0.0:9998
> +
> +
> +**3.** On Secondary VM's QEMU monitor, issue command::
> +
> + {"execute":"qmp_capabilities"}
> + {"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }
> + {"execute": "nbd-server-start", "arguments": {"addr": {"type": "inet", "data": {"host": "0.0.0.0", "port": "9999"} } } }
> + {"execute": "nbd-server-add", "arguments": {"device": "parent0", "writable": true } }
> +
> +Note:
> + a. The qmp command ``nbd-server-start`` and ``nbd-server-add`` must be run
> + before running the qmp command migrate on primary QEMU
> + b. Active disk, hidden disk and nbd target's length should be the
> + same.
> + c. It is better to put active disk and hidden disk in ramdisk. They
> + will be merged into the parent disk on failover.
> +
> +**4.** On Primary VM's QEMU monitor, issue command::
> +
> + {"execute":"qmp_capabilities"}
> + {"execute": "human-monitor-command", "arguments": {"command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}}
> + {"execute": "x-blockdev-change", "arguments":{"parent": "colo-disk0", "node": "replication0" } }
> + {"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }
> + {"execute": "migrate", "arguments": {"uri": "tcp:127.0.0.2:9998" } }
> +
> +Note:
> + a. There should be only one NBD Client for each primary disk.
> + b. The qmp command line must be run after running qmp command line in
> + secondary qemu.
> +
> +**5.** After the above steps, you will see, whenever you make changes to PVM, SVM will be synced.
> +You can issue command ``{ "execute": "migrate-set-parameters" , "arguments":{ "x-checkpoint-delay": 2000 } }``
> +to change the idle checkpoint period time
> +
> +Failover test
> +^^^^^^^^^^^^^
> +You can kill one of the VMs and Failover on the surviving VM:
> +
> +If you killed the Secondary, then follow "Primary Failover".
> +After that, if you want to resume the replication, follow "Primary resume replication"
> +
> +If you killed the Primary, then follow "Secondary Failover".
> +After that, if you want to resume the replication, follow "Secondary resume replication"
> +
> +Primary Failover
> +~~~~~~~~~~~~~~~~
> +The Secondary died, resume on the Primary::
> +
> + {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "child": "children.1"} }
> + {"execute": "human-monitor-command", "arguments":{ "command-line": "drive_del replication0" } }
> + {"execute": "object-del", "arguments":{ "id": "comp0" } }
> + {"execute": "object-del", "arguments":{ "id": "iothread1" } }
> + {"execute": "object-del", "arguments":{ "id": "m0" } }
> + {"execute": "object-del", "arguments":{ "id": "redire0" } }
> + {"execute": "object-del", "arguments":{ "id": "redire1" } }
> + {"execute": "x-colo-lost-heartbeat" }
> +
> +Secondary Failover
> +~~~~~~~~~~~~~~~~~~
> +The Primary died, resume on the Secondary and prepare to become the new Primary::
> +
> + {"execute": "nbd-server-stop"}
> + {"execute": "x-colo-lost-heartbeat"}
> +
> + {"execute": "object-del", "arguments":{ "id": "f2" } }
> + {"execute": "object-del", "arguments":{ "id": "f1" } }
> + {"execute": "chardev-remove", "arguments":{ "id": "red1" } }
> + {"execute": "chardev-remove", "arguments":{ "id": "red0" } }
> +
> + {"execute": "chardev-add", "arguments":{ "id": "mirror0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9003" } }, "server": true } } } }
> + {"execute": "chardev-add", "arguments":{ "id": "compare1", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9004" } }, "server": true } } } }
> + {"execute": "chardev-add", "arguments":{ "id": "compare0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": true } } } }
> + {"execute": "chardev-add", "arguments":{ "id": "compare0-0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": false } } } }
> + {"execute": "chardev-add", "arguments":{ "id": "compare_out", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": true } } } }
> + {"execute": "chardev-add", "arguments":{ "id": "compare_out0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": false } } } }
> +
> +Primary resume replication
> +~~~~~~~~~~~~~~~~~~~~~~~~~~
> +Resume replication after new Secondary is up.
> +
> +Start the new Secondary (Steps 2 and 3 above), then on the Primary::
> +
> + {"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.2:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }
> +
> +Wait until disk is synced, then::
> +
> + {"execute": "stop"}
> + {"execute": "block-job-cancel", "arguments":{ "device": "resync"} }
> +
> + {"execute": "human-monitor-command", "arguments":{ "command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.2,file.port=9999,file.export=parent0,node-name=replication0"}}
> + {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }
> +
> + {"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }
> + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }
> + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }
> + {"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }
> + {"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }
> +
> + {"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }
> + {"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.2:9998" } }
> +
> +Note:
> +If this Primary previously was a Secondary, then we need to insert the
> +filters before the filter-rewriter by using the
> +""insert": "before", "position": "id=rew0"" Options. See below.
> +
> +Secondary resume replication
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +Become Primary and resume replication after new Secondary is up. Note
> +that now 127.0.0.1 is the Secondary and 127.0.0.2 is the Primary.
> +
> +Start the new Secondary (Steps 2 and 3 above, but with primary_ip=127.0.0.2),
> +then on the old Secondary::
> +
> + {"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.1:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }
> +
> +Wait until disk is synced, then::
> +
> + {"execute": "stop"}
> + {"execute": "block-job-cancel", "arguments":{ "device": "resync" } }
> +
> + {"execute": "human-monitor-command", "arguments":{ "command-line": "drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=127.0.0.1,file.port=9999,file.export=parent0,node-name=replication0"}}
> + {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }
> +
> + {"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }
> + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }
> + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }
> + {"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }
> + {"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }
> +
> + {"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }
> + {"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.1:9998" } }
> +
> +TODO
> +----
> +1. Support shared storage.
> +2. Develop the heartbeat part.
> +3. Reduce checkpoint VM’s downtime while doing checkpoint.
>
> --
> 2.39.5
>
© 2016 - 2026 Red Hat, Inc.