Mark Williamson wrote:
Rather than trying to sample how many pCPUs the domain gets to run on, perhaps
it would be better to monitor the total time its vCPUs are being scheduled
*somewhere*. Then you can just compare whether your pCPU time allowance
corresponds to your SLA.
This way the domain still doesn't need to know which specific CPUs it gets
scheduled on, but you can get all the information you need?
VMware for example handles this information in a similar way. Having the
total consumed CPU time (cpu_time) for a VM inside the VM (which is only
available in dom0 at the moment) one can calculate how many computing
power is available.
Lets consider, that my VM has 2 VCPUs configured. The VM furthermore is
configured to run on 2 physical CPUs, and this is also the SLA between
the hosting provider and the customer. But, another VM is also running
on these 2 physical CPU's. Having the possibility to check the cpu_time
on a frequent base, e.g. seconds, one would be able to check, if the
guaranteed phsical CPUs are available. To check this, simply generate a
high load inside the VM, and if the cpu_time increases every second by
the value of 2, both physical CPUs are available. In case the cpu_time
only increases by the value on 1 or 1,5 it is clear, that the SLA is not
fullfilled.
Is it possbile to provide this information to the domU (if explicitly
enabled in dom0)?
The third possibility is to setup a dedicated VM which interacts between
all available dom0's and all available domU's. But this is the last
possible solution I'd prefer, because a third instance to manage is a
third source of errors.
I'm still not sure why the domU would need to know the host's hostname though?
Or is it just as a fallback if the CPU data isn't directly available?
This is meant to be the fallback, in case it is not possible to get any
data from the hypervisor. I'm not sure, but having HVM setups running,
getting data might be very difficult. Therefore, having a fallback
(which can be turned on, but will be turned off by default) can be very
convenient.
Cheers,
Mark
Cheers,
Hannes
--
* Hannes Kuehnemund
* SAP Linuxlab
* SAP AG
* Dietmar Hopp Allee 16
* 69190 Walldorf, Germany
T +49 6227 7-40615
F +49 6227 78-34584
mailto: hannes.kuehnemund@xxxxxxx
http://www.sap.com
Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Henning Kagermann (Sprecher/CEO),
Léo Apotheker (stellvertretender Sprecher/Deputy CEO),
Werner Brandt, Claus Heinrich, Gerhard Oswald, Peter Zencke
Vorsitzender des Aufsichtsrats/Chairperson of the SAP
Supervisory Board: Hasso Plattner
Registergericht/Commercial Register Mannheim No HRB 350269
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder
sonstige vertrauliche Informationen enthalten. Sollten Sie
diese E-Mail irrtümlich erhalten haben, ist Ihnen eine
Kenntnisnahme des Inhalts, eine Vervielfältigung oder
Weitergabe der E-Mail ausdrücklich untersagt. Bitte
benachrichtigen Sie uns und vernichten Sie die empfangene
E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged,
undisclosed, or otherwise confidential information. If you have
received this e-mail in error, you are hereby notified that any
review, copying, or distribution of it is strictly prohibited.
Please inform us immediately and destroy the original
transmittal. Thank you for your cooperation.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home