blob: 58c86b0b0d92ebe04af6d6dd0bf41554fbfd0091 (
plain) (
blame)
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
|
graphic: 0.738
performance: 0.737
x86: 0.710
device: 0.706
architecture: 0.631
hypervisor: 0.618
socket: 0.568
user-level: 0.557
KVM: 0.515
semantic: 0.502
PID: 0.501
register: 0.495
network: 0.468
vnc: 0.464
permissions: 0.460
mistranslation: 0.446
files: 0.418
VMM: 0.417
ppc: 0.415
boot: 0.412
risc-v: 0.409
kernel: 0.407
peripherals: 0.373
virtual: 0.368
TCG: 0.284
arm: 0.279
debug: 0.274
i386: 0.257
assembly: 0.200
disk driver with iothread setting hangs live migrations
Per report raised at https://bugzilla.redhat.com/show_bug.cgi?id=1790093
Description of problem:
A disk driver definition using iothread parameter causes live migration with copy storage to hang during or just before the final ram sync stage.
Interestingly, having the scsi controller as a separate iothread does not trigger the issue.
Version-Release number of selected component (if applicable):
I can reproduce this on centos7 with qemu-ev and with centos 8:
qemu-kvm-ev-2.12.0-33.1.el7_7.4.x86_64
qemu-kvm-2.12.0-65.module_el8.0.0+189+f9babebb.5.x86_64
Steps to Reproduce:
1. Create a definition with 1 iothread on the disk image:
<driver name='qemu' type='qcow2' iothread='1' />
2. Issue a live migrate request like: virsh migrate --live --copy-storage-all vm qemu+tcp://remote/system
3. Live migrate on source copies storage and then hangs at 80-99%, I guess during the ram copy phase.
Keeping exactly the same config but without the iothread on the disk driver has successful migrations every time.
Initially I suspected that https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg03048.html may have addressed this issue, but I think because you're not using backup it might not.
...Oh, qemu 2.12 is *quite old* and not supported upstream anymore. Do you have the ability to test on a more modern QEMU version?
If not, I might need to redirect you back to the RH Bugzilla for issues with the stable version they ship for RH/CentOS. I don't want to play bug tracker pingpong with you, so I'll leave this issue open (but marked "incomplete") and wait for a reply.
--js
I will try the newest version as you suggest. However please note that this is a redhat/centos 2.12 version which means it has a load of the newest patches on it so probably closer to a 4-series than real 2.12...
Mark
[Expired for QEMU because there has been no activity for 60 days.]
|