On Tue, Jul 20, 2010 at 11:04:01AM +0200, Jiri Denemark wrote:
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.
I wanted to (ab)use virConnectCompareCPU to roughly tell a certain cpu model (say athlon) can be emulated on my host. I now see that this is not going to happen, and I'll have to do my own feature set comparison.
I don't see the problem in virConnectCompareCPU() that prevents you using it for that ? Checking whether a certain cpu model can be emulated on a host is exactly what's virConnectCompareCPU is design todo. We explicitly did not want apps to need to do a manual feature set comparison because that's just horrible code to get right.
Yeah exactly, I don't really get what makes you think you can't use virConnectCompareCPU.
You can use <cpu match='exact'> <model>athlon</model> </cpu> to check if athlon model is compatible with host CPU (regardless on vendor).
If you are not interested in some features (say 3dnowext), you can use <cpu match='exact'> <model>athlon</model> <feature name='3dnowext' policy='disable'/> </cpu>
And if you only want to run on an AuthenticAMD CPU, you'd use <cpu match='exact'> <model>athlon</model> <vendor>AMD</vendor> <feature name='3dnowext' policy='disable'/> </cpu>
Oh, I assumed that the fact the <vendor>AMD</vendor> appears in the model definition of "athlon", it is implicit whenever <model>athlon</model> is mentioned. The semantics missing <vendor> is "don't care about vendor", and the semantics of a missing <feature> is "enforce the feature". This is a bit confusing.
However it all depends on what you mean by "emulated". If you really want to check if the CPU can be emulated on your machine as in "I have this old pentium3 box but I want to run a VM which requires the newest Opteron even though most of its features will be emulated in software" then virConnectCompareCPU is not currently able to check that for you. But I doubt you could check this by doing your own feature set comparison since you'd need to go deep into qemu and check what features it can emulate in software.
Anyway, if you think virConnectCompareCPU is not doing what it should or if you have ideas on improving feature set comparison, please share them here. It's better to improve libvirt than doing all by yourself within your application.
Well, I would like to tell in advance if starting up domain is going to be rejected due to incompatibility between guest cpu and host cpu in the relevant hypervisor (qemu -cpu bla,enforce style).