On Wed, Jun 07, 2017 at 02:52:05 +0800, wang.yi59(a)zte.com.cn wrote:
But in the condition I described, libvirt has no chance to translate
into a different model
It doesn't need to translate the CPU model because QEMU supports
core2duo CPU model. It's hard to imagine with such an ancient CPU model,
let's consider Skylake-Client CPU model for now... If you try to use
this model with old QEMU which does not know anything about
Skylake-Client, fallback='allow' will allow libvirt to translate the CPU
model to something else known to the old QEMU, but adding all features
present in Skylake-Client and missing from the other model. With
fallback='forbid' libvirt will just refuse to start the domain because
the CPU model is unknown to QEMU.
In addition to this libvirt checks whether such CPU can even be provided
by QEMU/KVM on the current host. And in your case libvirt decides
core2duo cannot be used on your host because it does not support
'monitor' feature required for the core2duo CPU model. You either need
to use a different CPU model or explicitly disable this feature. Another
option is to add check='none' attribute into the <cpu> element to tell
libvirt to ignore this. In such a case QEMU will likely disable the
feature itself.
Jirka