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