Hi Dong-In,
> Thank you for the valuable information. That's exactly what I want to get.
> Let me tell you what I'm doing now. I'm extending OpenStack (cloud
> computing infrastructure) for high performance computing. Before spawning a
> cloud instance, I want to check the full capability of the host machine
> because I will use KVM. With the expanded feature list, a cloud user can
> decide which node to choose. For example, if a users needs sse4.1, the
> scheduler should search for a node having sse4.1 as its feature.
As Daniel already said, you can use virConnectCompareCPU() with desired cpu
xml and it will tell you if the desired cpu is compatible with host cpu on
that node. However, you cannot specify features without also saying what cpu
model you need. So in case you are only interested in sse4.1 feature
regardless on cpu model you can use the following cpu xml:
<cpu>
<model>pentium</model>
<feature name='sse4.1'/>
</cpu>
The 'pentium' model has almost no features and is most likely compatible with
every modern cpu you may have.
> OpensStack currently calls virConnectGetCapabilities at the start of a node
> to get its capability. And it returns not fully expanded feature list. Could
> you tell me how I can exand it fully?
Libvirt doesn't support expanding models since that only makes sense (to some
extend) for certain cpu architecture. You could theoretically expand it
yourself but cpu_map.xml is internal to libvirt and its schema may change any
time.
The idea (also already described by Daniel) is that applications should not
really need to expand the features. An application should rather construct cpu
xml according to user's needs and ask libvirt (via virConnectCompareCPU) if
the requested cpu is compatible with host CPU.
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list