Package: qemu-system-x86
Version: 1:2.6+dfsg-3
1. What Works:
Migrating from a host CPU without tsc_scale to one with it works
perfectly. e.g. from an AMD Phenom II x4 940 to an AMD FX-8150.
Migrating from a host CPU without tsc_scale to another one without it
also works perfectly. e.g. from an AMD Phenom II 1090T to an AMD Phenom
II x4 940, and back and forth as often as I like, without a problem.
I haven't tested it yet, but given that migration works for lots of
people I assume that migrating from a host CPU with tsc_scale to another
one with it will also work perfectly. e.g. an FX-8150 to/from an
FX-8320.
2. What doesn't work:
Migrating from a CPU with tsc_scale to one without it **appears** to
migrate successfully, but the VM on the migration-target host uses 100%
CPU and hangs. e.g. from an AMD FX-8150 to an AMD Phenom II x4 940.
Migrating it back to the original host doesn't fix it. The only things
that can be done with the VM are force-reboot and force-shutdown.
There's no console or log output on the VM itself, the only indication
of any problem (apart from the 100% CPU utilisation & hang) is a message
in /var/log/libvirt/qemu/vmname.log on the migration-target host saying:
qemu-system-x86_64: warning: TSC frequency mismatch between VM and host,
and TSC scaling unavailable
IMO, that's shouldn't be just a warning. it's a fatal error.
NOTE: Disabling kvm_steal_time as recommended in several similar bug
reports and forum posts doesn't solve the problem.
AFAIK, there is no solution other than "Don't Do That". I'm not sure if
this is a bug in qemu or just a hardware incompatibility between old and
new (or not-quite-so-old) CPUs. Please forward upstream, they should
at least document the issue, even if it can't be fixed.
For a more detailed analysis/example of the problem, see:
http://unix.stackexchange.com/questions/296636/100-cpu-utilisation-and-hang-after-virsh-migrate
craig
--
craig sanders <c...@taz.net.au>
