So I couldn't indeed think of uses of "-cpu host" together with
migration. But if you're sure there is none, block it in QEMU.
There's no reason why this should be specific to libvirt.
It's not that there are no useful use cases, it is that we simply can't
guarantee it will work because (by design) "-cpu host" enables features
QEMU doesn't know about (so it doesn't know if migration is safe or
not). And that's the main use case for "-cpu host".
So, what about doing the following on QEMU 2.1:
* "-cpu host,migratable=yes":
* No invtsc
* Migration not blocked
* No feature flag unknown to QEMU will be enabled
* "-cpu host,migratable=no":
* invtsc enabled
* Unknown-to-QEMU features enabled
* Migration blocked
* "-cpu host":
* Same behavior as "-cpu host,migratable=yes"
* Release notes indicating that "-cpu host,migratable=no" is
required if the user doesn't care about migration and wants new
(unknown to QEMU) features to be available
I was going to propose making "migratable=no" the default after a few
releases, as I expect the majority of existing users of "-cpu host" to
not care about migration. But I am not sure, because there's less harm
in _not_ getting new bleeding edge features enabled, and those users
(and management software) can start using "migratable=no" if they really
want the new unmigratable features.