[Libvir] [PATCH] Xen: Support cpu_weight and cpu_cap for Xen.

[Richard W.M. Jones]

Daniel Veillard wrote:
> On Fri, Oct 26, 2007 at 12:15:38PM +0100, Richard W.M. Jones wrote:
>> Daniel Veillard wrote:
>>> So you are suggesting to add this to the XML, while for me this makes 
>>> little
>>> sense because of all this specificity.
>>> I have no doubt the patch would 'work' for you, but anybody using a 
>>> different
>>> hypervisor, or different scheduler, or even someone trying to understand 
>>> what
>>> those fields are would have no use or informations (your patch does not 
>>> provide
>>> documentation for the meaning of those attributes).
>>>
>>>  I have a problem with extending the XML in a way which makes sense
>>> only for one hypervisor, when using a specific scheduler, and without
>>> a proper definition for what the extension actually means. 
>>>  Also Those informations are highly runtime dependant, it's tuning,
>>> it is not critical at all to get that tuning to get the domain up and
>>> running, and once it is running you can actually use the libvirt API
>>> to make the scheduler tuning.
>>>
>>>  Can you explain why you absolutely want to have that tuning information
>>> in the XML itself ?
>> There's certainly a general problem here: how do we persist information 
>> like CPU pinning and scheduler information across domain shutdown to the 
>> next time that the domain starts up.  What is the current thinking about 
>> setting CPU pinning info when a domain boots?
> 
>   To me that's the same thing, CPU pinning and scheduler information are
> basically tuning informations. Maybe this is static, maybe this needs to
> change frequently, but we cannot assume the first case for the design.
> 
>   What would make more sense to me is to be able to save and restore
> tuning informations, per domain or for the full system at the virsh 
> level. For example something like:
>    virsh savetuning > tuning.data
>    or
>    virsh savetuning domain > tuning.data
> 
>  and
> 
>    virsh loadtuning tuning.data
> 
>   This would still be convenient for the user, especially for locked systems
> or systems where multiple different workload can be used depending on the
> demand, one would just need to save tuning for each of them. Tuning could be
> reloaded or readjusted ech time a domain is stopped/started or the whole node
> is rebooted.
>   The implementation could be done entierely in libvirt without having
> to change or extend existing APIs or behaviour.
> 
>   I can understand the need to make it easy for an user, I still don't
> think this means those tuning informations need to be associated to the
> domain definition, to me it is somehow orthogonal to the domain themselves
> and I would rather try to provide a good solution to the problem, than
> try to imitate how Xen was doing that.

[Resurrecting this old thread ...]

How about this as a plan?

(1) Add 'virsh savetuning' and 'virsh loadtuning' commands as Daniel 
Veillard has suggested above.  These would save the per-domain tuning 
information to an XML file

   <tuning>
     <pin vcpu="0" pcpu="0"/>
     <pin vcpu="1" pcpu="1"/>
     <!-- other stuff for cpu_weight, etc. -->
   </tuning>

(2) Modify 'virsh define' and 'virsh create' commands to add a 
'--with-tuning' flag, so that:

   virsh define foo.xml --with-tuning foo-tuning.xml

Which basically does the ordinary 'virsh define' step followed by 'virsh 
loadtuning'.

(3) Modify 'virsh save' to add '--save-tuning', so that:

   virsh save foo foo.img --save-tuning foo-tuning.xml

This captures the tuning information into the XML file, and is the same 
as doing an ordinary 'save' followed by 'virsh savetuning'.

	- - -

This doesn't change the libvirt API, nor does it deal with saving and 
restoring tuning information across restarts (but then I can't see how 
the autostart flag works for Xen at the moment at all ... a bug?)

I'm prepared to do this work if people think it's a good idea.

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20071218/2a527a36/attachment-0001.bin>