diff options
Diffstat (limited to 'results/classifier/108/other/1536487')
| -rw-r--r-- | results/classifier/108/other/1536487 | 101 |
1 files changed, 101 insertions, 0 deletions
diff --git a/results/classifier/108/other/1536487 b/results/classifier/108/other/1536487 new file mode 100644 index 00000000..ba4848cc --- /dev/null +++ b/results/classifier/108/other/1536487 @@ -0,0 +1,101 @@ +device: 0.905 +other: 0.898 +PID: 0.829 +KVM: 0.826 +semantic: 0.812 +graphic: 0.780 +performance: 0.758 +permissions: 0.739 +boot: 0.679 +socket: 0.665 +debug: 0.664 +files: 0.650 +network: 0.629 +vnc: 0.621 + +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. + |