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. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list