3:03 p.m.
On Thu, Mar 23, 2006 at 12:35:12PM -0800, Gareth S Bestor wrote:
I agree to some extent, but I might suggest that discovery and
exposure of
host system physical resources may be better left to other APIs, since such
functionality has widespread uses outside of virtualization management.
Since you bring it up, we - Open Source CIM interfaces for Xen, via libvirt
- are actually having to face this exact problem today, namely what is/are
good standardized cross-platform cross-distro Linux interfaces for exposing
physical hardware info necessary for virtual resource allocation. Right now
we have a some Open Source Linux CIM providers exposing h/w info mined out
of, say, /proc, but the architecture and distro ifdefs are getting out of
hand... You are quite correct in stating this requirement, and there seems
to be multiple candidates (SMBIOS, HPI, SNMP, etc) but I don't have a good
answer. My concern would be trying to add and solve this problem within the
scope of libvirt.
I don't think it is neccessary (or desirable) to solve the general resource
discovery problem within libvirt - I'd limit scope to only those resources
where there is a need for consistency with the VMM's view of resources.
Taking CPU enumeration as an example, if an app is to later instruct a VMM to
restrict scheduling of a domain's VCPUs to a particular set of host CPUs, then
it is critical to ensure the app's enumeration of host CPUs matches the way the
VMM enumerates them. eg CPU #1 in the VMM's world view, may appear as CPU #3
in /proc/cpuinfo. The most reliable way to avoid this & guarentee consistency
of view would be to have the app use the VMM for enumerating the CPUs.
Now while the app could talk to the VMM directly, it then looses the two key
benefits of libvirt - isolation from VMM comms protocol change & isolation
from underlying virtualization technology. Thus I think libvirt needs at least
some limited resource discovery capabilities.
Regards,
Dan.
|---------+------------------------------>
| | "Daniel P. |
| | Berrange" |
| | <berrange(a)redhat.co|
| | m> |
| | Sent by: |
| | libvir-list-bounces|
| | @redhat.com |
| | |
| | |
| | 03/23/06 08:04 AM |
| | Please respond to |
| | "Daniel P. |
| | Berrange" |
|---------+------------------------------>
>--------------------------------------------------------------------------------------------------------------------|
|
|
| To: libvir-list(a)redhat.com
|
| cc:
|
| Subject: [Libvir] RFC: requesting APIs for host physical resource discovery
|
>--------------------------------------------------------------------------------------------------------------------|
The current libvirt APIs allow the host's physical resources to be split up
and allocated to guest domains, however, there is no way to discover what
the available host resources actually are. Thus I would like to suggest the
inclusion of new APIs to enable host resource discovery. As a starting
point
I'd like to be able to query the following information:
* Number of physical CPUs - ability to enumerate the CPUs in the host,
both those currently present, and theoretical maximum (to take account
of hotplug).
* Amount of RAM - actual physical RAM present, and that available for
guest usage (eg discounting that reserved by a hypervisor or equiv)
* CPU relationship - ie ability to distinguish between CPUs which
are hyperthread siblings, on same core, or on separate sockets
Alonside these basic queries it would be desirable to add a further
resource
resource management API to allow for setting of a guest domain's CPU
affinity.
ie ability control what CPUs the VMM is allowed to schedule a domain on.
Once this first basic set of caapbilties for resource discovery are
provided
for, then I believe it will be neccessary to provide some more advanced
queries, in particular:
* NUMA topology - ability to enumerate NUMA nodes, the CPUs associated
with each node & the RAM range mapped to that node
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496
-=|
|=- Perl modules: http://search.cpan.org/~danberr/
-=|
|=- Projects: http://freshmeat.net/~danielpb/
-=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
-=|
--
Libvir-list mailing list
Libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|