Hi Jirka,Thanks for your reviewing. But in the condition I described, libvirt
has no chance to translate into a different model, because it has failed in the
virCPUCompare before translate and the start of the domain will report the
error, it that correct? For example, a host lacks "monitor" feature, which
means that we can't see "monitor" flag when we run "cat /proc/cpuinfo", it will
report error when we try to start the domain with core2duo model:"error: the
CPU is incompatible with host CPU: Host CPU does not providerequired features:
monitor"Yi Wang
Original
Sender:JiriDenemark
To:WangYi10129963
Cc:libvir-list@redhat.comLiuJianJun10033482
Date:2017-06-07 01:56:02
Subject:Re: [libvirt] [PATCH] qemu: Starting a domain with custom model
andallowed-fallback failed when host lacks some CPU features
On Tue, Jun 06, 2017 at 12:23:01 -0400, Yi Wang wrote:> An attemp to start a
domain requesting a custom CPU model, core2duo, for> example, will fail if some
feature that the model needs doesn't exist in that> host, even though fallback
attibute is set allow:> "error: the CPU is incompatible with host CPU: Host CPU
does not provide> required features: monitor"> Of course we can start that
domain through forbidding that feature, but> that may not be flexible.NACK, it
works exactly as designed. The fallback attribute would make adifference only
if core2duo CPU model was not supported by QEMU, thenlibvirt would translate it
into a different supported one.Jirka
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
