On Wed, Jun 07, 2017 at 02:52:05 +0800, wang.yi59@xxxxxxxxxx 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
