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?
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