Comment 14 for bug 1536331

OTOH it might be good that I set up all these combinations already before thinking of kvm-ipxe-precise - that provided good coverage now :-)

So with that set up and kvm-ipxe-precise installed on the target I get this combination of test results. Always keeping the combination of qemu/libvirt that belonged together - so old means qemu&libvirt of the 1374612 fix, while new is as of today.

Define:
P(old) libvirt 0.9.8-2ubuntu17.19 qemu 1.0+noroms-0ubuntu14.18
P(new) libvirt 0.9.8-2ubuntu17.23 qemu 1.0+noroms-0ubuntu14.30
T(old) libvirt 1.2.2-0ubuntu13.1.6 qemu 2.0.0+dfsg-2ubuntu1.6
T(new) libvirt 1.2.2-0ubuntu13.1.19 qemu 2.0.0+dfsg-2ubuntu1.28
T(no alias) libvirt 1.2.2-0ubuntu13.1.19 qemu 2.0.0+dfsg-2ubuntu1.29
.29 is a local build dropping the double alias in Trusty qemu

Testing migrations types: converted-to-pc-1.0 / created-as-pc-1.0 / pc-1.0-qemu-kvm
P(old) -> T(old): working / working / fail
P(old) -> T(new): working / working / fail
P(new) -> T(new): working / working / fail
P(new) -> T(no alias): working / working / working

So it seems not to be a regression at least.
Instead back then fixing the migration of the former default pc-1.0 type it was missed, that the newly introduced pc-1.0-qemu-kvm/pc-1.0-precise did not migrate.
That would also explain why things calmed down (all former started guests migrated fine).
But later then reports came in - as the later started guests got the new pc-1.0-qemu-kvm type by default.

Fortunately it seems that dropping the false alias in Trusty fixes the migration for all cases.
Building that in a ppa now and preparing for a wider migration test run (e.g. from T->X with that) using my migration testsuite at https://code.launchpad.net/~ubuntu-server/ubuntu/+source/qemu-migration-test/+git/qemu-migration-test/+ref/master

ppa builds will be in https://launchpad.net/~paelzer/+archive/ubuntu/qemu-machine-type-dev