[Libvir] Question on acquiring cpuTime in struct _virDomainInfo

Jan Michael jan.michael at cern.ch
Thu May 24 16:38:30 UTC 2007

Hi Daniel,

first I'd like to thank you for your speedy answer and the suggested  
solution. But I think it doesn't fit to my problem.
The program I write is a sensor, which is executed by a given time  
intervall. So I'm not able to cache the domain handles.

But that rises another question in my mind. Till now I assumed that I  
have to get a new domain handle to receive updated information  
(cpuTime) from the domain, do I? Else I could avoid a second call to  
get a second domain handle.



On 23.05.2007, at 15:30, Daniel P. Berrange wrote:
> On Wed, May 23, 2007 at 02:35:47PM +0200, Jan Michael wrote:
>> In the described stress situation it tooks about an average of 4
>> seconds to make the following to function calls, which provide me the
>> cpuTime of a domain
>>             dom_old = virDomainLookupByID(conn_old, listOfDomains 
>> [i]);
>> 	    ret = virDomainGetInfo(dom_old, &info_old);
> It is the virDomainLookupByID call which is killing your performance
> here  - it has to go to XenD, and XenD does *incredibly* stupid stuff
> talking to xenstored
> http://lists.xensource.com/archives/html/xen-devel/2007-04/ 
> msg00663.html
> So each call takes ~1 second under normal conditions, so 4 seconds
> isn't surprising under high load.
> This is one of the reasons why the Xen driver in libvirt tries to talk
> directly to the hypervisor if at all possible - the HV impl of most
> calls is at least x1000 faster than the XenD impl.  
> virConnectListDomains
> & virDomainGetInfo both have impls which talk to the HV so they are  
> very
> fast to execute. The virDomainLookupByID has no HV impl, since we need
> to talk to XenD to find the guests name & UUID info.
>> Here are the stats from my latest measurement:
>> 		old cpuTime		new cpuTime
>> Domain-0:	3s 4294835190ms		3s 4294849513ms
>> stornode:	5s 580501ms 		6s 4294550691ms
>> worknode:	6s 4294546809ms		5s 582761ms
>> That leads to results in cpu utilisation computation for the node,
>> which are much lower, around 75%, than the real value (100%) would  
>> be.
>> One solution would be to add the measured time make those calls to
>> used cpuTime. But this in turn can cause calculations of to high
>> values because I don't really know in which point in time the value
>> is written to the structure.
> The approach I'd recommend is to make sure you avoid calling  
> virDomainLookupByID.
> If you've got a simple loop like pseduo-code...
>      forever() {
>          ids = virConnectListDomains()
>          foreach (id in ids) {
>             dom = virDomainLookupByID(id)
>             info = virDomainGetInfo(dom)
>          }
>      }
> Then, you need to pull the virDomainLookupByID out of the inner loop.
> Basically cache the 'virDomainPtr' handles - you can detect new  
> domains,
> or shutdown domains after each call to virConnectListDomains(). So  
> with
> correct caching of handles, you should only need to suffer the  
> performance
> hit from virDomainLookupByID once per guest - the first time it starts
>> Nevertheless is xentop showing me every time the correct cpu-
>> utilisation of each of my domains. So that I conclude, that this
>> problem must have something to do with libvirt API.
> Its just libvirt exposing the undering inadequacies of XenD &  
> XenStoreD
> impl & performance :-(
> 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  -=|

More information about the libvir-list mailing list