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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
