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
|
other: 0.132
device: 0.126
PID: 0.094
semantic: 0.089
KVM: 0.089
graphic: 0.075
vnc: 0.055
performance: 0.054
permissions: 0.053
socket: 0.051
boot: 0.048
files: 0.047
debug: 0.047
network: 0.040
KVM: 0.686
files: 0.055
debug: 0.047
device: 0.043
PID: 0.038
other: 0.028
socket: 0.022
semantic: 0.017
vnc: 0.014
network: 0.013
performance: 0.012
boot: 0.010
graphic: 0.009
permissions: 0.008
Unable to migrate pc-i440fx-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1
When migrating a pc-i440fc-2.4 KVM guest from QEMU 2.5.0 to QEMU 2.4.1, the target QEMU errors out:
qemu-system-x86_64: error while loading state for instance 0x0 of device 'fw_cfg'
This appears to be related to the addition of a DMA interface to fw_cfg last October:
http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg04568.html
"info qtree" on the source QEMU shows that the DMA interface for fw_cfg had been enabled:
bus: main-system-bus
type System
...
dev: fw_cfg_io, id ""
iobase = 1296 (0x510)
dma_iobase = 1300 (0x514)
dma_enabled = true
Incidentally, this guest had just undergone a migration from QEMU 2.4.0 to QEMU 2.5.0, so it looks like DMA was enabled simply through the migration.
It seems to me that the DMA interface for fw_cfg should only be enabled on pc-i440fx-2.5 machines or higher.
Hi,
Proxmox users have reported same bug (qemu 2.5 with pc-i440fc-2.4 not migrating to qemu 2.4.1)
https://forum.proxmox.com/threads/cant-live-migrate-after-dist-upgrade.26097/
I don't have verified yet, but it seem to be related.
http://thread.gmane.org/gmane.comp.emulators.qemu/390272/focus=391042
sent a patch: http://thread.gmane.org/gmane.comp.emulators.qemu/395014
Fix committed in e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a.
Note: Also affects Migration Xenial->Trusty (tested and ran into the same issue, that was how I found the bug) and very likely also Yakkety->Trusty.
qemu | 2.0.0+dfsg-2ubuntu1.27 | trusty-security | source
qemu | 1:2.5+dfsg-5ubuntu10.4 | xenial-updates | source
Subscribing server Team to look at this in the scope of the qemu packaging SRU work for Xenial.
Migrating a VM from xenial -> trusty (or anything moving backward) is
not supported.
Hi Serge I agree to "created on xenial -> migrating to trusty" not being supported.
I already tended to even say "created on xenial with the Trusty machine type -> migrating to trusty" is not supported as well (at least it is failing for all combos I tried.
But I wonder how far "anything moving backward" should go.
Especially I found that the "created on Trusty, migrated to xenial (works), but later migrated back to trusty (fails)" seems affected by it as well.
I'd have thought that this would be supported. What is you opinion on this more specific case?
You might ask on #virt for the opinion there, but I don't believe
migrating backward is supported in any case. t->x->t doesn't change
the fact that there is x->t.
> Especially I found that the "created on Trusty, migrated to xenial
> (works), but later migrated back to trusty (fails)" seems affected by
> it as well.
The first migration of the t->x->t sequence does not really matter (if
anything it could introduce _more_ bugs!), so if x->t is not supported
then neither is t->x->t.
The upstream QEMU project doesn't have the manpower to test and support
backwards migration. We try not to break it, and in this case there
was an easy fix and we suggest that Canonical backports it. However,
in general it's not guaranteed to work.
The fix is commit e6915b5f3a874a467a9a65f7ec1d6ef8d251a51a.
Serge, Paulo - thank you both!
I already had the patch but I think it was good to discuss and list the expected behavior not only for me, but for whoever else that comes by this or a similar case.
I backported this and tried my tests again, but this alone isn't sufficient to get the T->X->T working (which is effectively 2.0->2.5->2.0).
Wily (2.4) is already out of service, so setting this to won't fix.
Thanks for your guidance, but that now properly known I'll set the Xenial task to won't fix for now.
|