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

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.