On Tue, Oct 17, 2017 at 01:15:43PM +0200, Jiri Denemark wrote: > 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. Reviewed-by: Pavel Hrdina <phrdina@xxxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
