This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] host information in domU over /proc or /sys filesystem

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] host information in domU over /proc or /sys filesystem
From: Hannes Kuehnemund <hannes.kuehnemund@xxxxxxx>
Date: Tue, 29 May 2007 18:04:41 +0200
Cc: Mark Williamson <mark.williamson@xxxxxxxxxxxx>
Delivery-date: Tue, 29 May 2007 09:03:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200705282011.45762.mark.williamson@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4655B186.8050209@xxxxxxx> <200705282011.45762.mark.williamson@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20070326)
Mark Williamson wrote:
>> This feature is very important for quality of service aspects. How
>> many physical CPU do I have? How many CPU time can I use?
I'm not exactly sure whether a domU needs to know this? or do you mean dom0 specifically?

Actually, the domU itself shouldn't know this, but maybe an application running in domU. Imagine the following situation:

Three party setup:

1) Software vendor
2) Hosting provider
3) Customer (using Software from 1) and a virtual machine from 2))

In case the hosting provider changes something in the setup, the performance decreases and Customer complains at the software vendor the really bad performance of the software sold. Having no chance to get at least number of physical cpu's assigned to domU makes problem solving impossible. This theoretical setup would need the interaction of a third party, the Hosting provider.

If there would be a possibility for the hosting provider to provide this information (physical CPU assigned) to a domU, reduces the costs and time spend for interaction getting a third party involved in a support call. The information which physical CPU's are assigned to a domU does not affect security or encapsulation, because the domU does _not_ know how many physical CPU's dom0 has at all or how many of them are assigned to other VM's.

The number of physical CPUs the domain's VCPUs are being scheduled across might change dynamically. You can, however, change the number of VCPUs a domain is allocated as an indication of how many CPUs it should try to optimise for.

That it changes dynamically is not a problem at all. We would collect the data, how many physical CPU's are assigned on a 5 minute base in our application to keep track of it. We then can check if response times correlate with number of physical CPU's.

There's also /sys/hypervisor which contains some relevant information.

Yes, that for the hint. Unfortunately is data is not enough :(

dom0 is permitted to access more detailed information about the host machine through a hypercall (use "xm info" to see what's available).
Other important > information would the real memory and the hostname of the
host machine.
I'm not sure why a domU would need to know the hostname of the host machine? Also, this could change during migration, so it's not a stable value.

In case nothing like the physical CPU assignment will be implemented, domU must know, which CIM server to query to get this kind of information. I know that this value will change, and because of this we need the information. If the domO would stay the same all the time, I could set a parameter in my software to query the CIM server directly, which wouldn't work after a migration.

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.



Basically all this information is provided by other virtualization
technologies as read only values. Having a huge hosting solution with
enterprise software running in virtual machines depends on these quality
of service aspects. Having a black box makes debugging of performance
issues impossible and thus the whole solution is not usable.

Is it possible to provide such a solution with Xen (of course only if
enabled in dom0 due to security reasons!) over the /proc or /sysfs?



* Hannes Kuehnemund
* SAP Linuxlab
* Dietmar Hopp Allee 16
* 69190 Walldorf, Germany
T  +49 6227 7-40615
F  +49 6227 78-34584
mailto: hannes.kuehnemund@xxxxxxx

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

<Prev in Thread] Current Thread [Next in Thread>