On Tue, Oct 17, 2017 at 12:57:10 +0200, Pavel Hrdina wrote:
On Wed, Oct 11, 2017 at 12:11:16PM +0200, Jiri Denemark wrote:
> The host CPU definition from host capabilities may contain features
> unknown to QEMU. Thus whenever we want to use this CPU definition, we
> have to filter the unknown features.
Might be nice to explicitly mention in the commit message that this
fixes the issue while reconnecting to QEMU process started by old
libvirt that keeps "host-model" in the status XML. Took me some time
to figure that out :).
Yeah, sorry about it. What about the following commit message?
When reconnecting to a domain started with a host-model CPU which was
started by old libvirt that did not replace host-model with the real CPU
definition, libvirt replaces the host-model CPU with the CPU from
capabilities (because this is what the old libvirt did when it started
the domain). Without this patch libvirt could use features unknown to
QEMU in the CPU definition which replaced the original host-model CPU.
Such domain would keep running just fine, but any attempt to migrate it
will fail and once the domain is saved or snapshotted, restoring it
would fail too.
In other words whenever we want to use this CPU definition, we have to
filter the unknown features.
Jirka