Hi Jirka,
Thank you for the answer.
It is a very useful method to checking if the host can support a feature is useful.
However, OpenStack uses libvirt in a different way.
OpenStack collects the capabilities of a machine when the machine registers itself to the cloud as a compute node.
virConnectGetCapabilities() is used to get the capabilities.
After that, OpenStack does not inquire the compute node of its capabilities.
OpenStack keeps that information of the compute nodes in the cloud (it can be in a database or in an ephemeral storage).
When a request is sent to the scheduler with required features (such as sse4.1), the scheduler looks for a match.
Here, the scheduler does not inquire the compute nodes if they support that feature.
But, the scheduler uses the capabilities information it received from the compute nodes.
(Changing this communication flow may need a big changes in OpenStack, which many people try to avoid.)
In this model, OpenStack must get and keep the full feature list.
And I thought it would be best to get the fully expanded feature list using virConnectGetCapabilities().
To that purpose, I've applied the following changes in the file libvirt-0.9.1/src/cpu/cpu_x86.c.
Do you have any concern about the changes?
Or could you suggest any better approach?
--- libvirt-0.9.1/src/cpu/cpu_x86.c 2011-03-01 02:03:31.000000000 -0500
+++ cpu_x86.c 2011-05-18 09:42:32.909470642 -0400
@@ -477,8 +477,9 @@
if ((vendor = x86DataToVendor(copy, map)) &&
!(cpu->vendor = strdup(vendor->name)))
goto no_memory;
-
+#if 0 // dkang: commented out to return full feature
x86DataSubtract(copy, modelData);
+#endif
x86DataSubtract(modelData, data);
/* because feature policy is ignored for host CPU */
Thanks,
Dong-In
----- Original Message -----
From: "Jiri Denemark" <jdenemar@xxxxxxxxxx>
To: "Dong-In David Kang" <dkang@xxxxxxx>
Cc: libvir-list@xxxxxxxxxx
Sent: Tuesday, May 17, 2011 2:21:18 PM
Subject: Re: inquiry, get native capabilities of the host
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