> > By specifying <vendor> element in CPU requirements a guest can be > > restricted to run only on CPUs by a given vendor. Host CPU vendor is > > also specified in capabilities XML. > > > > The vendor is checked when migrating a guest but it's not forced, i.e., > > a guest configured without <vendor> element can be freely migrated. ... > > src/cpu/cpu_map.xml | 6 + > > Why did you add <vendor> tags to several of the models there? Does qemu > (-no-kvm) have any problem emulating athlon on an Intel host? Honestly, I don't know if qemu has any problems emulating them but it doesn't really matter. The <vendor> emelement in cpu_map.xml is used when libvirt decides what model should be used for describing host CPU. > And how about adding policy='disable' attribute, so that I can ask > virConnectCompareCPU to ignore this particular incompatibility, as I do > with <feature> items? Just don't use <vendor> tag in your XML. In other words, if you specify <vendor> in domain XML (or it's cpu fragment used by virConnectCompareCPU) and your host CPU is made by different vendor, the CPUs won't match. If you don't specify <vendor>, you don't care about the vendor and neither does libvirt. I hope it's more clear now. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list