Philippe Berthault wrote:
Daniel Veillard a écrit :
On Tue, Aug 01, 2006 at 05:06:59PM +0200, Philippe Berthault wrote:
[snip]
I wonder how people are most likely to use those APIs. Building scenarios
like:
- physical CPU is to be locked to serve only VCPU N in domain D
- domain A and domain B should be served by disjoint physical CPUs sets
- monitoring
are the most common uses I would guess but I may be wrong.
First would require:
- virDomainPinVcpu I guess
Second would require:
- virDomainGetCpus and a number of calls to limit to sets :-\
The last one is likely to require getting full maps, and since it is likely
to be called frequently the cheapest the better
If people who expressed interest on the list about VCPU function could
express their principal use case it may help getting the APIs right.
About third point (monitoring): I think the virDomainGetVcpus API
isn't adequate for this purpose. It would be better to have an API (to
be defined) which give the state of all physical CPUs because it's the
hardware resources we need to monitor, not the virtual ones. The
virDomainGetVcpus API permits to obtain the relation
vcpu->physical_cpu(s) but for monitoring usage, it's not interesting.
It would be better to have an API which give the reverse relation :
physical_cpu->vpcu(s) independently of domains and give the physical
CPU usage. With the virDomainGetVcpus API, it's impossible to
determine if a physical cpu is underused or overused and it's this
information we need to know for monitoring and for load-balancing.
I agree and do not see a monitoring use case for these APIs, only
setting/getting configuration. Perhaps we need more host-side entry
points, for monitoring host resources?
Regards,
Jim