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 withouta 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list