@samitouri / QOSamiQemu / commits / f22952551e

Convert colo main documentation to restructuredText

Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Zhang Chen <zhangckid@gmail.com> Signed-off-by: Lukas Straub <lukasstraub2@web.de> Link: https://lore.kernel.org/qemu-devel/20260302-colo_unit_test_multifd-v11-14-d653fb3b1d80@web.de [replaced license boilerplate with SPDX line] Signed-off-by: Fabiano Rosas <farosas@suse.de>

Lukas Straub committed Mar 2, 2026 at 12:45 UTC f22952551ec4bcb7b3c1fea4563e3163b0943b1d

4 files changed +361 -335

MAINTAINERS

+1 -1

@@ -3887,7 +3887,7 @@ F: migration/multifd-colo.*

3887 F: include/migration/colo.h

3888 F: include/migration/failover.h

3889 F: tests/qtest/migration/colo-tests.c

3890 -F: docs/COLO-FT.txt

3890 +F: docs/system/qemu-colo.rst

3891

3892 COLO Proxy

3893 M: Zhang Chen <zhangckid@gmail.com>

docs/COLO-FT.txt deleted

-334

@@ -1,334 +0,0 @@

1 -COarse-grained LOck-stepping Virtual Machines for Non-stop Service

2 -----------------------------------------

6 -

7 -This work is licensed under the terms of the GNU GPL, version 2 or later.

8 -See the COPYING file in the top-level directory.

9 -

10 -This document gives an overview of COLO's design and how to use it.

11 -

12 -== Background ==

13 -Virtual machine (VM) replication is a well known technique for providing

14 -application-agnostic software-implemented hardware fault tolerance,

15 -also known as "non-stop service".

16 -

17 -COLO (COarse-grained LOck-stepping) is a high availability solution.

18 -Both primary VM (PVM) and secondary VM (SVM) run in parallel. They receive the

19 -same request from client, and generate response in parallel too.

20 -If the response packets from PVM and SVM are identical, they are released

21 -immediately. Otherwise, a VM checkpoint (on demand) is conducted.

22 -

23 -== Architecture ==

24 -

25 -The architecture of COLO is shown in the diagram below.

26 -It consists of a pair of networked physical nodes:

27 -The primary node running the PVM, and the secondary node running the SVM

28 -to maintain a valid replica of the PVM.

29 -PVM and SVM execute in parallel and generate output of response packets for

30 -client requests according to the application semantics.

31 -

32 -The incoming packets from the client or external network are received by the

33 -primary node, and then forwarded to the secondary node, so that both the PVM

34 -and the SVM are stimulated with the same requests.

35 -

36 -COLO receives the outbound packets from both the PVM and SVM and compares them

37 -before allowing the output to be sent to clients.

38 -

39 -The SVM is qualified as a valid replica of the PVM, as long as it generates

40 -identical responses to all client requests. Once the differences in the outputs

41 -are detected between the PVM and SVM, COLO withholds transmission of the

42 -outbound packets until it has successfully synchronized the PVM state to the SVM.

43 -

44 - Primary Node Secondary Node

45 -+------------+ +-----------------------+ +------------------------+ +------------+

46 -| | | HeartBeat +<----->+ HeartBeat | | |

47 -| Primary VM | +-----------+-----------+ +-----------+------------+ |Secondary VM|

48 -| | | | | |

49 -| | +-----------|-----------+ +-----------|------------+ | |

52 -| | | +--------+ | | +--------+ | | |

53 -| | | +---------------+ | | +---------------+ | | |

54 -| | | | VM Checkpoint +-------------->+ VM Checkpoint | | | |

55 -| | | +---------------+ | | +---------------+ | | |

56 -|Requests<--------------------------\ /-----------------\ /--------------------->Requests|

57 -| | | ^ ^ | | | | | | |

58 -|Responses+---------------------\ /-|-|------------\ /-------------------------+Responses|

59 -| | | | | | | | | | | | | | | |

60 -| | | +-----------+ | | | | | | | | | | +----------+ | | |

63 -| | | ++----------+ v v | | | | | v v | +---------++ | | |

64 -| | | |+-----------+-+-+-++| | ++-+--+-+---------+ | | | |

65 -| | | || COLO Proxy || | | COLO Proxy | | | | |

66 -| | | || (compare packet || | |(adjust sequence | | | | |

67 -| | | ||and mirror packet)|| | | and ACK) | | | | |

68 -| | | |+------------+---+-+| | +-----------------+ | | | |

69 -+------------+ +-----------------------+ +------------------------+ +------------+

70 -+------------+ | | | | +------------+

72 -+------------+ | | | | +------------+

73 -+---------------------------------------+ +----------------------------------------+

75 -+---------------------------------------+ +----------------------------------------+

76 - | | | |

77 - +--------------v+ +---------v---+--+ +------------------+ +v-------------+

79 - +---------------+ +----------------+ +------------------+ +--------------+

80 -

81 -

82 -== Components introduction ==

83 -

84 -You can see there are several components in COLO's diagram of architecture.

85 -Their functions are described below.

86 -

87 -HeartBeat:

88 -Runs on both the primary and secondary nodes, to periodically check platform

89 -availability. When the primary node suffers a hardware fail-stop failure,

90 -the heartbeat stops responding, the secondary node will trigger a failover

91 -as soon as it determines the absence.

92 -

93 -COLO disk Manager:

94 -When primary VM writes data into image, the colo disk manager captures this data

95 -and sends it to secondary VM's which makes sure the context of secondary VM's

96 -image is consistent with the context of primary VM 's image.

97 -For more details, please refer to docs/block-replication.txt.

98 -

99 -Checkpoint/Failover Controller:

100 -Modifications of save/restore flow to realize continuous migration,

101 -to make sure the state of VM in Secondary side is always consistent with VM in

102 -Primary side.

103 -

104 -COLO Proxy:

105 -Delivers packets to Primary and Secondary, and then compare the responses from

106 -both side. Then decide whether to start a checkpoint according to some rules.

107 -Please refer to docs/colo-proxy.txt for more information.

108 -

109 -Note:

110 -HeartBeat has not been implemented yet, so you need to trigger failover process

111 -by using 'x-colo-lost-heartbeat' command.

112 -

113 -== COLO operation status ==

114 -

115 -+-----------------+

116 -| |

117 -| Start COLO |

118 -| |

119 -+--------+--------+

120 - |

121 - | Main qmp command:

122 - | migrate-set-capabilities with x-colo

123 - | migrate

124 - |

125 - v

126 -+--------+--------+

127 -| |

128 -| COLO running |

129 -| |

130 -+--------+--------+

131 - |

132 - | Main qmp command:

133 - | x-colo-lost-heartbeat

134 - | or

135 - | some error happened

136 - v

137 -+--------+--------+

138 -| | send qmp event:

139 -| COLO failover | COLO_EXIT

140 -| |

141 -+-----------------+

142 -

143 -COLO use the qmp command to switch and report operation status.

144 -The diagram just shows the main qmp command, you can get the detail

145 -in test procedure.

146 -

147 -== Test procedure ==

148 -Note: Here we are running both instances on the same host for testing,

149 -change the IP Addresses if you want to run it on two hosts. Initially

150 -127.0.0.1 is the Primary Host and 127.0.0.2 is the Secondary Host.

151 -

152 -== Startup qemu ==

153 -1. Primary:

154 -Note: Initially, $imagefolder/primary.qcow2 needs to be copied to all hosts.

155 -You don't need to change any IP's here, because 0.0.0.0 listens on any

156 -interface. The chardev's with 127.0.0.1 IP's loopback to the local qemu

157 -instance.

158 -

159 -# imagefolder="/mnt/vms/colo-test-primary"

160 -

161 -# qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \

162 - -device piix3-usb-uhci -device usb-tablet -name primary \

163 - -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \

164 - -device rtl8139,id=e0,netdev=hn0 \

165 - -chardev socket,id=mirror0,host=0.0.0.0,port=9003,server=on,wait=off \

166 - -chardev socket,id=compare1,host=0.0.0.0,port=9004,server=on,wait=on \

167 - -chardev socket,id=compare0,host=127.0.0.1,port=9001,server=on,wait=off \

168 - -chardev socket,id=compare0-0,host=127.0.0.1,port=9001 \

169 - -chardev socket,id=compare_out,host=127.0.0.1,port=9005,server=on,wait=off \

170 - -chardev socket,id=compare_out0,host=127.0.0.1,port=9005 \

171 - -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \

172 - -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out \

173 - -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \

174 - -object iothread,id=iothread1 \

175 - -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,\

176 -outdev=compare_out0,iothread=iothread1 \

177 - -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\

178 -children.0.file.filename=$imagefolder/primary.qcow2,children.0.driver=qcow2 -S

179 -

180 -2. Secondary:

181 -Note: Active and hidden images need to be created only once and the

182 -size should be the same as primary.qcow2. Again, you don't need to change

183 -any IP's here, except for the $primary_ip variable.

184 -

185 -# imagefolder="/mnt/vms/colo-test-secondary"

186 -# primary_ip=127.0.0.1

187 -

188 -# qemu-img create -f qcow2 $imagefolder/secondary-active.qcow2 10G

189 -

190 -# qemu-img create -f qcow2 $imagefolder/secondary-hidden.qcow2 10G

191 -

192 -# qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \

193 - -device piix3-usb-uhci -device usb-tablet -name secondary \

194 - -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \

195 - -device rtl8139,id=e0,netdev=hn0 \

196 - -chardev socket,id=red0,host=$primary_ip,port=9003,reconnect-ms=1000 \

197 - -chardev socket,id=red1,host=$primary_ip,port=9004,reconnect-ms=1000 \

198 - -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \

199 - -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \

200 - -object filter-rewriter,id=rew0,netdev=hn0,queue=all \

201 - -drive if=none,id=parent0,file.filename=$imagefolder/primary.qcow2,driver=qcow2 \

202 - -drive if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,\

203 -top-id=colo-disk0,file.file.filename=$imagefolder/secondary-active.qcow2,\

204 -file.backing.driver=qcow2,file.backing.file.filename=$imagefolder/secondary-hidden.qcow2,\

205 -file.backing.backing=parent0 \

206 - -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\

207 -children.0=childs0 \

208 - -incoming tcp:0.0.0.0:9998

209 -

210 -

211 -3. On Secondary VM's QEMU monitor, issue command

212 -{"execute":"qmp_capabilities"}

213 -{"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }

214 -{"execute": "nbd-server-start", "arguments": {"addr": {"type": "inet", "data": {"host": "0.0.0.0", "port": "9999"} } } }

215 -{"execute": "nbd-server-add", "arguments": {"device": "parent0", "writable": true } }

216 -

217 -Note:

218 - a. The qmp command nbd-server-start and nbd-server-add must be run

219 - before running the qmp command migrate on primary QEMU

220 - b. Active disk, hidden disk and nbd target's length should be the

221 - same.

222 - c. It is better to put active disk and hidden disk in ramdisk. They

223 - will be merged into the parent disk on failover.

224 -

225 -4. On Primary VM's QEMU monitor, issue command:

226 -{"execute":"qmp_capabilities"}

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

228 -{"execute": "x-blockdev-change", "arguments":{"parent": "colo-disk0", "node": "replication0" } }

229 -{"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }

230 -{"execute": "migrate", "arguments": {"uri": "tcp:127.0.0.2:9998" } }

231 -

232 - Note:

233 - a. There should be only one NBD Client for each primary disk.

234 - b. The qmp command line must be run after running qmp command line in

235 - secondary qemu.

236 -

237 -5. After the above steps, you will see, whenever you make changes to PVM, SVM will be synced.

238 -You can issue command '{ "execute": "migrate-set-parameters" , "arguments":{ "x-checkpoint-delay": 2000 } }'

239 -to change the idle checkpoint period time

240 -

241 -6. Failover test

242 -You can kill one of the VMs and Failover on the surviving VM:

243 -

244 -If you killed the Secondary, then follow "Primary Failover". After that,

245 -if you want to resume the replication, follow "Primary resume replication"

246 -

247 -If you killed the Primary, then follow "Secondary Failover". After that,

248 -if you want to resume the replication, follow "Secondary resume replication"

249 -

250 -== Primary Failover ==

251 -The Secondary died, resume on the Primary

252 -

253 -{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "child": "children.1"} }

254 -{"execute": "human-monitor-command", "arguments":{ "command-line": "drive_del replication0" } }

255 -{"execute": "object-del", "arguments":{ "id": "comp0" } }

256 -{"execute": "object-del", "arguments":{ "id": "iothread1" } }

257 -{"execute": "object-del", "arguments":{ "id": "m0" } }

258 -{"execute": "object-del", "arguments":{ "id": "redire0" } }

259 -{"execute": "object-del", "arguments":{ "id": "redire1" } }

260 -{"execute": "x-colo-lost-heartbeat" }

261 -

262 -== Secondary Failover ==

263 -The Primary died, resume on the Secondary and prepare to become the new Primary

264 -

265 -{"execute": "nbd-server-stop"}

266 -{"execute": "x-colo-lost-heartbeat"}

267 -

268 -{"execute": "object-del", "arguments":{ "id": "f2" } }

269 -{"execute": "object-del", "arguments":{ "id": "f1" } }

270 -{"execute": "chardev-remove", "arguments":{ "id": "red1" } }

271 -{"execute": "chardev-remove", "arguments":{ "id": "red0" } }

272 -

273 -{"execute": "chardev-add", "arguments":{ "id": "mirror0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9003" } }, "server": true } } } }

274 -{"execute": "chardev-add", "arguments":{ "id": "compare1", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9004" } }, "server": true } } } }

275 -{"execute": "chardev-add", "arguments":{ "id": "compare0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": true } } } }

276 -{"execute": "chardev-add", "arguments":{ "id": "compare0-0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": false } } } }

277 -{"execute": "chardev-add", "arguments":{ "id": "compare_out", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": true } } } }

278 -{"execute": "chardev-add", "arguments":{ "id": "compare_out0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": false } } } }

279 -

280 -== Primary resume replication ==

281 -Resume replication after new Secondary is up.

282 -

283 -Start the new Secondary (Steps 2 and 3 above), then on the Primary:

284 -{"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.2:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }

285 -

286 -Wait until disk is synced, then:

287 -{"execute": "stop"}

288 -{"execute": "block-job-cancel", "arguments":{ "device": "resync"} }

289 -

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

291 -{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }

292 -

293 -{"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }

294 -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }

295 -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }

296 -{"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }

297 -{"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }

298 -

299 -{"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }

300 -{"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.2:9998" } }

301 -

302 -Note:

303 -If this Primary previously was a Secondary, then we need to insert the

304 -filters before the filter-rewriter by using the

305 -""insert": "before", "position": "id=rew0"" Options. See below.

306 -

307 -== Secondary resume replication ==

308 -Become Primary and resume replication after new Secondary is up. Note

309 -that now 127.0.0.1 is the Secondary and 127.0.0.2 is the Primary.

310 -

311 -Start the new Secondary (Steps 2 and 3 above, but with primary_ip=127.0.0.2),

312 -then on the old Secondary:

313 -{"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.1:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }

314 -

315 -Wait until disk is synced, then:

316 -{"execute": "stop"}

317 -{"execute": "block-job-cancel", "arguments":{ "device": "resync" } }

318 -

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

320 -{"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }

321 -

322 -{"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }

323 -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }

324 -{"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }

325 -{"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }

326 -{"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }

327 -

328 -{"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }

329 -{"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.1:9998" } }

330 -

331 -== TODO ==

332 -1. Support shared storage.

333 -2. Develop the heartbeat part.

334 -3. Reduce checkpoint VM’s downtime while doing checkpoint.

docs/system/index.rst

@@ -42,3 +42,4 @@ or Hypervisor.Framework.

42 nitro

43 vm-templating

44 sriov

45 + qemu-colo

docs/system/qemu-colo.rst new

+359

@@ -0,0 +1,359 @@

1 +.. SPDX-License-Identifier: GPL-2.0-or-later

2 +

3 +Qemu COLO Fault Tolerance

4 +=========================

5 +

9 +

10 +This document gives an overview of COLO's design and how to use it.

11 +

12 +Background

13 +----------

14 +Virtual machine (VM) replication is a well known technique for providing

15 +application-agnostic software-implemented hardware fault tolerance,

16 +also known as "non-stop service".

17 +

18 +COLO (COarse-grained LOck-stepping) is a high availability solution.

19 +Both primary VM (PVM) and secondary VM (SVM) run in parallel. They receive the

20 +same request from client, and generate response in parallel too.

21 +If the response packets from PVM and SVM are identical, they are released

22 +immediately. Otherwise, a VM checkpoint (on demand) is conducted.

23 +

24 +Architecture

25 +------------

26 +The architecture of COLO is shown in the diagram below.

27 +It consists of a pair of networked physical nodes:

28 +The primary node running the PVM, and the secondary node running the SVM

29 +to maintain a valid replica of the PVM.

30 +PVM and SVM execute in parallel and generate output of response packets for

31 +client requests according to the application semantics.

32 +

33 +The incoming packets from the client or external network are received by the

34 +primary node, and then forwarded to the secondary node, so that both the PVM

35 +and the SVM are stimulated with the same requests.

36 +

37 +COLO receives the outbound packets from both the PVM and SVM and compares them

38 +before allowing the output to be sent to clients.

39 +

40 +The SVM is qualified as a valid replica of the PVM, as long as it generates

41 +identical responses to all client requests. Once the differences in the outputs

42 +are detected between the PVM and SVM, COLO withholds transmission of the

43 +outbound packets until it has successfully synchronized the PVM state to the SVM.

44 +

45 +Overview::

46 +

47 + Primary Node Secondary Node

48 + +------------+ +-----------------------+ +------------------------+ +------------+

49 + | | | HeartBeat +<----->+ HeartBeat | | |

50 + | Primary VM | +-----------+-----------+ +-----------+------------+ |Secondary VM|

51 + | | | | | |

52 + | | +-----------|-----------+ +-----------|------------+ | |

55 + | | | +--------+ | | +--------+ | | |

56 + | | | +---------------+ | | +---------------+ | | |

57 + | | | | VM Checkpoint +-------------->+ VM Checkpoint | | | |

58 + | | | +---------------+ | | +---------------+ | | |

59 + |Requests<--------------------------\ /-----------------\ /--------------------->Requests|

60 + | | | ^ ^ | | | | | | |

61 + |Responses+---------------------\ /-|-|------------\ /-------------------------+Responses|

62 + | | | | | | | | | | | | | | | |

63 + | | | +-----------+ | | | | | | | | | | +----------+ | | |

66 + | | | ++----------+ v v | | | | | v v | +---------++ | | |

67 + | | | |+-----------+-+-+-++| | ++-+--+-+---------+ | | | |

68 + | | | || COLO Proxy || | | COLO Proxy | | | | |

69 + | | | || (compare packet || | |(adjust sequence | | | | |

70 + | | | ||and mirror packet)|| | | and ACK) | | | | |

71 + | | | |+------------+---+-+| | +-----------------+ | | | |

72 + +------------+ +-----------------------+ +------------------------+ +------------+

73 + +------------+ | | | | +------------+

75 + +------------+ | | | | +------------+

76 + +---------------------------------------+ +----------------------------------------+

78 + +---------------------------------------+ +----------------------------------------+

79 + | | | |

80 + +--------------v+ +---------v---+--+ +------------------+ +v-------------+

82 + +---------------+ +----------------+ +------------------+ +--------------+

83 +

84 +Components introduction

85 +^^^^^^^^^^^^^^^^^^^^^^^

86 +You can see there are several components in COLO's diagram of architecture.

87 +Their functions are described below.

88 +

89 +HeartBeat

90 +~~~~~~~~~

91 +Runs on both the primary and secondary nodes, to periodically check platform

92 +availability. When the primary node suffers a hardware fail-stop failure,

93 +the heartbeat stops responding, the secondary node will trigger a failover

94 +as soon as it determines the absence.

95 +

96 +COLO disk Manager

97 +~~~~~~~~~~~~~~~~~

98 +When primary VM writes data into image, the colo disk manager captures this data

99 +and sends it to secondary VM's which makes sure the context of secondary VM's

100 +image is consistent with the context of primary VM 's image.

101 +For more details, please refer to docs/block-replication.txt.

102 +

103 +Checkpoint/Failover Controller

104 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

105 +Modifications of save/restore flow to realize continuous migration,

106 +to make sure the state of VM in Secondary side is always consistent with VM in

107 +Primary side.

108 +

109 +COLO Proxy

110 +~~~~~~~~~~

111 +Delivers packets to Primary and Secondary, and then compare the responses from

112 +both side. Then decide whether to start a checkpoint according to some rules.

113 +Please refer to docs/colo-proxy.txt for more information.

114 +

115 +Note:

116 +HeartBeat has not been implemented yet, so you need to trigger failover process

117 +by using 'x-colo-lost-heartbeat' command.

118 +

119 +COLO operation status

120 +^^^^^^^^^^^^^^^^^^^^^

121 +

122 +Overview::

123 +

124 + +-----------------+

125 + | |

126 + | Start COLO |

127 + | |

128 + +--------+--------+

129 + |

130 + | Main qmp command:

131 + | migrate-set-capabilities with x-colo

132 + | migrate

133 + |

134 + v

135 + +--------+--------+

136 + | |

137 + | COLO running |

138 + | |

139 + +--------+--------+

140 + |

141 + | Main qmp command:

142 + | x-colo-lost-heartbeat

143 + | or

144 + | some error happened

145 + v

146 + +--------+--------+

147 + | | send qmp event:

148 + | COLO failover | COLO_EXIT

149 + | |

150 + +-----------------+

151 +

152 +

153 +COLO use the qmp command to switch and report operation status.

154 +The diagram just shows the main qmp command, you can get the detail

155 +in test procedure.

156 +

157 +Test procedure

158 +--------------

159 +Note: Here we are running both instances on the same host for testing,

160 +change the IP Addresses if you want to run it on two hosts. Initially

161 +``127.0.0.1`` is the Primary Host and ``127.0.0.2`` is the Secondary Host.

162 +

163 +Startup qemu

164 +^^^^^^^^^^^^

165 +**1. Primary**:

166 +Note: Initially, ``$imagefolder/primary.qcow2`` needs to be copied to all hosts.

167 +You don't need to change any IP's here, because ``0.0.0.0`` listens on any

168 +interface. The chardev's with ``127.0.0.1`` IP's loopback to the local qemu

169 +instance::

170 +

171 + # imagefolder="/mnt/vms/colo-test-primary"

172 +

173 + # qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \

174 + -device piix3-usb-uhci -device usb-tablet -name primary \

175 + -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \

176 + -device rtl8139,id=e0,netdev=hn0 \

177 + -chardev socket,id=mirror0,host=0.0.0.0,port=9003,server=on,wait=off \

178 + -chardev socket,id=compare1,host=0.0.0.0,port=9004,server=on,wait=on \

179 + -chardev socket,id=compare0,host=127.0.0.1,port=9001,server=on,wait=off \

180 + -chardev socket,id=compare0-0,host=127.0.0.1,port=9001 \

181 + -chardev socket,id=compare_out,host=127.0.0.1,port=9005,server=on,wait=off \

182 + -chardev socket,id=compare_out0,host=127.0.0.1,port=9005 \

183 + -object filter-mirror,id=m0,netdev=hn0,queue=tx,outdev=mirror0 \

184 + -object filter-redirector,netdev=hn0,id=redire0,queue=rx,indev=compare_out \

185 + -object filter-redirector,netdev=hn0,id=redire1,queue=rx,outdev=compare0 \

186 + -object iothread,id=iothread1 \

187 + -object colo-compare,id=comp0,primary_in=compare0-0,secondary_in=compare1,\

188 + outdev=compare_out0,iothread=iothread1 \

189 + -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\

190 + children.0.file.filename=$imagefolder/primary.qcow2,children.0.driver=qcow2 -S

191 +

192 +

193 +**2. Secondary**:

194 +Note: Active and hidden images need to be created only once and the

195 +size should be the same as ``primary.qcow2``. Again, you don't need to change

196 +any IP's here, except for the ``$primary_ip`` variable::

197 +

198 + # imagefolder="/mnt/vms/colo-test-secondary"

199 + # primary_ip=127.0.0.1

200 +

201 + # qemu-img create -f qcow2 $imagefolder/secondary-active.qcow2 10G

202 +

203 + # qemu-img create -f qcow2 $imagefolder/secondary-hidden.qcow2 10G

204 +

205 + # qemu-system-x86_64 -enable-kvm -cpu qemu64,kvmclock=on -m 512 -smp 1 -qmp stdio \

206 + -device piix3-usb-uhci -device usb-tablet -name secondary \

207 + -netdev tap,id=hn0,vhost=off,helper=/usr/lib/qemu/qemu-bridge-helper \

208 + -device rtl8139,id=e0,netdev=hn0 \

209 + -chardev socket,id=red0,host=$primary_ip,port=9003,reconnect-ms=1000 \

210 + -chardev socket,id=red1,host=$primary_ip,port=9004,reconnect-ms=1000 \

211 + -object filter-redirector,id=f1,netdev=hn0,queue=tx,indev=red0 \

212 + -object filter-redirector,id=f2,netdev=hn0,queue=rx,outdev=red1 \

213 + -object filter-rewriter,id=rew0,netdev=hn0,queue=all \

214 + -drive if=none,id=parent0,file.filename=$imagefolder/primary.qcow2,driver=qcow2 \

215 + -drive if=none,id=childs0,driver=replication,mode=secondary,file.driver=qcow2,\

216 + top-id=colo-disk0,file.file.filename=$imagefolder/secondary-active.qcow2,\

217 + file.backing.driver=qcow2,file.backing.file.filename=$imagefolder/secondary-hidden.qcow2,\

218 + file.backing.backing=parent0 \

219 + -drive if=ide,id=colo-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\

220 + children.0=childs0 \

221 + -incoming tcp:0.0.0.0:9998

222 +

223 +

224 +**3.** On Secondary VM's QEMU monitor, issue command::

225 +

226 + {"execute":"qmp_capabilities"}

227 + {"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }

228 + {"execute": "nbd-server-start", "arguments": {"addr": {"type": "inet", "data": {"host": "0.0.0.0", "port": "9999"} } } }

229 + {"execute": "nbd-server-add", "arguments": {"device": "parent0", "writable": true } }

230 +

231 +Note:

232 + a. The qmp command ``nbd-server-start`` and ``nbd-server-add`` must be run

233 + before running the qmp command migrate on primary QEMU

234 + b. Active disk, hidden disk and nbd target's length should be the

235 + same.

236 + c. It is better to put active disk and hidden disk in ramdisk. They

237 + will be merged into the parent disk on failover.

238 +

239 +**4.** On Primary VM's QEMU monitor, issue command::

240 +

241 + {"execute":"qmp_capabilities"}

242 + {"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"}}

243 + {"execute": "x-blockdev-change", "arguments":{"parent": "colo-disk0", "node": "replication0" } }

244 + {"execute": "migrate-set-capabilities", "arguments": {"capabilities": [ {"capability": "x-colo", "state": true } ] } }

245 + {"execute": "migrate", "arguments": {"uri": "tcp:127.0.0.2:9998" } }

246 +

247 +Note:

248 + a. There should be only one NBD Client for each primary disk.

249 + b. The qmp command line must be run after running qmp command line in

250 + secondary qemu.

251 +

252 +**5.** After the above steps, you will see, whenever you make changes to PVM, SVM will be synced.

253 +You can issue command ``{ "execute": "migrate-set-parameters" , "arguments":{ "x-checkpoint-delay": 2000 } }``

254 +to change the idle checkpoint period time

255 +

256 +Failover test

257 +^^^^^^^^^^^^^

258 +You can kill one of the VMs and Failover on the surviving VM:

259 +

260 +If you killed the Secondary, then follow "Primary Failover".

261 +After that, if you want to resume the replication, follow "Primary resume replication"

262 +

263 +If you killed the Primary, then follow "Secondary Failover".

264 +After that, if you want to resume the replication, follow "Secondary resume replication"

265 +

266 +Primary Failover

267 +~~~~~~~~~~~~~~~~

268 +The Secondary died, resume on the Primary::

269 +

270 + {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "child": "children.1"} }

271 + {"execute": "human-monitor-command", "arguments":{ "command-line": "drive_del replication0" } }

272 + {"execute": "object-del", "arguments":{ "id": "comp0" } }

273 + {"execute": "object-del", "arguments":{ "id": "iothread1" } }

274 + {"execute": "object-del", "arguments":{ "id": "m0" } }

275 + {"execute": "object-del", "arguments":{ "id": "redire0" } }

276 + {"execute": "object-del", "arguments":{ "id": "redire1" } }

277 + {"execute": "x-colo-lost-heartbeat" }

278 +

279 +Secondary Failover

280 +~~~~~~~~~~~~~~~~~~

281 +The Primary died, resume on the Secondary and prepare to become the new Primary::

282 +

283 + {"execute": "nbd-server-stop"}

284 + {"execute": "x-colo-lost-heartbeat"}

285 +

286 + {"execute": "object-del", "arguments":{ "id": "f2" } }

287 + {"execute": "object-del", "arguments":{ "id": "f1" } }

288 + {"execute": "chardev-remove", "arguments":{ "id": "red1" } }

289 + {"execute": "chardev-remove", "arguments":{ "id": "red0" } }

290 +

291 + {"execute": "chardev-add", "arguments":{ "id": "mirror0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9003" } }, "server": true } } } }

292 + {"execute": "chardev-add", "arguments":{ "id": "compare1", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "0.0.0.0", "port": "9004" } }, "server": true } } } }

293 + {"execute": "chardev-add", "arguments":{ "id": "compare0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": true } } } }

294 + {"execute": "chardev-add", "arguments":{ "id": "compare0-0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9001" } }, "server": false } } } }

295 + {"execute": "chardev-add", "arguments":{ "id": "compare_out", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": true } } } }

296 + {"execute": "chardev-add", "arguments":{ "id": "compare_out0", "backend": {"type": "socket", "data": {"addr": { "type": "inet", "data": { "host": "127.0.0.1", "port": "9005" } }, "server": false } } } }

297 +

298 +Primary resume replication

299 +~~~~~~~~~~~~~~~~~~~~~~~~~~

300 +Resume replication after new Secondary is up.

301 +

302 +Start the new Secondary (Steps 2 and 3 above), then on the Primary::

303 +

304 + {"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.2:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }

305 +

306 +Wait until disk is synced, then::

307 +

308 + {"execute": "stop"}

309 + {"execute": "block-job-cancel", "arguments":{ "device": "resync"} }

310 +

311 + {"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"}}

312 + {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }

313 +

314 + {"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }

315 + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }

316 + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }

317 + {"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }

318 + {"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }

319 +

320 + {"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }

321 + {"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.2:9998" } }

322 +

323 +Note:

324 +If this Primary previously was a Secondary, then we need to insert the

325 +filters before the filter-rewriter by using the

326 +""insert": "before", "position": "id=rew0"" Options. See below.

327 +

328 +Secondary resume replication

329 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~

330 +Become Primary and resume replication after new Secondary is up. Note

331 +that now 127.0.0.1 is the Secondary and 127.0.0.2 is the Primary.

332 +

333 +Start the new Secondary (Steps 2 and 3 above, but with primary_ip=127.0.0.2),

334 +then on the old Secondary::

335 +

336 + {"execute": "drive-mirror", "arguments":{ "device": "colo-disk0", "job-id": "resync", "target": "nbd://127.0.0.1:9999/parent0", "mode": "existing", "format": "raw", "sync": "full"} }

337 +

338 +Wait until disk is synced, then::

339 +

340 + {"execute": "stop"}

341 + {"execute": "block-job-cancel", "arguments":{ "device": "resync" } }

342 +

343 + {"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"}}

344 + {"execute": "x-blockdev-change", "arguments":{ "parent": "colo-disk0", "node": "replication0" } }

345 +

346 + {"execute": "object-add", "arguments":{ "qom-type": "filter-mirror", "id": "m0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "tx", "outdev": "mirror0" } }

347 + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire0", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "indev": "compare_out" } }

348 + {"execute": "object-add", "arguments":{ "qom-type": "filter-redirector", "id": "redire1", "insert": "before", "position": "id=rew0", "netdev": "hn0", "queue": "rx", "outdev": "compare0" } }

349 + {"execute": "object-add", "arguments":{ "qom-type": "iothread", "id": "iothread1" } }

350 + {"execute": "object-add", "arguments":{ "qom-type": "colo-compare", "id": "comp0", "primary_in": "compare0-0", "secondary_in": "compare1", "outdev": "compare_out0", "iothread": "iothread1" } }

351 +

352 + {"execute": "migrate-set-capabilities", "arguments":{ "capabilities": [ {"capability": "x-colo", "state": true } ] } }

353 + {"execute": "migrate", "arguments":{ "uri": "tcp:127.0.0.1:9998" } }

354 +

355 +TODO

356 +----

357 +1. Support shared storage.

358 +2. Develop the heartbeat part.

359 +3. Reduce checkpoint VM’s downtime while doing checkpoint.