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). -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list