1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
permissions: 0.938
graphic: 0.927
debug: 0.924
register: 0.923
virtual: 0.918
semantic: 0.918
architecture: 0.911
performance: 0.905
device: 0.903
assembly: 0.900
user-level: 0.899
arm: 0.898
PID: 0.878
kernel: 0.878
network: 0.876
socket: 0.873
boot: 0.870
mistranslation: 0.853
risc-v: 0.847
files: 0.843
TCG: 0.840
hypervisor: 0.837
peripherals: 0.825
vnc: 0.823
VMM: 0.800
KVM: 0.789
x86: 0.786
i386: 0.776
ppc: 0.754
COLO unable to failover to secondary VM
I test COLO feature on my host following docs/COLO-FT.txt in qemu folder, but fail to failover to secondary VM.
Is there any mistake in my execution steps?
Execution environment:
QEMU v2.12.0-rc4
OS: Ubuntu 16.04.3 LTS
Kernel: Linux 4.4.35
Secondary VM IP: noted as "a.b.c.d"
Execution steps:
# Primary
${COLO_PATH}/x86_64-softmmu/qemu-system-x86_64 \
-enable-kvm \
-m 512M \
-smp 2 \
-qmp stdio \
-vnc :7 \
-name primary \
-device piix3-usb-uhci \
-device usb-tablet \
-netdev tap,id=tap0,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=tap0 \
-drive if=virtio,id=primary-disk0,driver=quorum,read-pattern=fifo,vote-threshold=1,\
children.0.file.filename=${IMG_PATH},\
children.0.driver=raw -S
# Secondary
${COLO_PATH}/x86_64-softmmu/qemu-system-x86_64 \
-enable-kvm \
-m 512M \
-smp 2 \
-qmp stdio \
-vnc :8 \
-name secondary \
-device piix3-usb-uhci \
-device usb-tablet \
-netdev tap,id=tap1,vhost=off \
-device virtio-net-pci,id=net-pci0,netdev=tap1 \
-drive if=none,id=secondary-disk0,file.filename=${IMG_PATH},driver=raw,node-name=node0 \
-drive if=virtio,id=active-disk0,driver=replication,mode=secondary,\
file.driver=qcow2,top-id=active-disk0,\
file.file.filename=$ACTIVE_DISK,\
file.backing.driver=qcow2,\
file.backing.file.filename=$HIDDEN_DISK,\
file.backing.backing=secondary-disk0 \
-incoming tcp:0:8888
# Enter into Secondary:
{'execute':'qmp_capabilities'}
{ 'execute': 'nbd-server-start',
'arguments': {'addr': {'type': 'inet', 'data': {'host': 'a.b.c.d', 'port': '8889'} } }
}
{'execute': 'nbd-server-add', 'arguments': {'device': 'secondary-disk0', 'writable': true } }
# Enter into Primary:
{'execute':'qmp_capabilities'}
{'execute': 'human-monitor-command',
'arguments': {
'command-line': 'drive_add -n buddy driver=replication,mode=primary,file.driver=nbd,file.host=a.b.c.d,file.port=8889,file.export=secondary-disk0,node-name=nbd_client0'
}
}
{ 'execute':'x-blockdev-change', 'arguments':{'parent': 'primary-disk0', 'node': 'nbd_client0' } }
{ 'execute': 'migrate-set-capabilities',
'arguments': {'capabilities': [ {'capability': 'x-colo', 'state': true } ] } }
{ 'execute': 'migrate', 'arguments': {'uri': 'tcp:a.b.c.d:8888' } }
# To test failover
Primary
{ 'execute': 'x-blockdev-change', 'arguments': {'parent': 'primary-disk0', 'child': 'children.1'}}
{ 'execute': 'human-monitor-command','arguments': {'command-line': 'drive_del nbd_client0'}}
Secondary
{ 'execute': 'nbd-server-stop' }
Stop Primary
Send ^C signal to terminate PVM.
Secondary
{ "execute": "x-colo-lost-heartbeat" }
# Result:
Primary (Use ^C to terminate)
qemu-system-x86_64: Can't receive COLO message: Input/output error
qemu-system-x86_64: terminating on signal 2
{"timestamp": {"seconds": 1531815575, "microseconds": 997696}, "event": "SHUTDOWN", "data": {"guest":false}}
Secondary
{ 'execute': 'nbd-server-stop' }
{"return": {}}
{ "execute": "x-colo-lost-heartbeat" }
{"return": {}}
qemu-system-x86_64: Can't receive COLO message: Input/output error
Segmentation fault
I also meet the same problem.
Does anybody have solutions for this problem?
The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.
[Expired for QEMU because there has been no activity for 60 days.]
|