[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] Re: Virtual CPU functions



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]