On Tue, Dec 18, 2007 at 02:53:09PM +0000, Richard W.M. Jones wrote: > 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> I have early code but never commited it, it doesn't do much yet, but yes that was basicaly my plan > (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'. > > - - - yeah, I think it's reasonnable since it doesn't change the C api and is clearly a virsh extension. > 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. Sounds fine to me, ideally make the virsh extension as a separate module to allow easy copying in other user's applications. I had defined: int virDomainSaveTuningTo(xmlBufferPtr buf, virDomainPtr dom, int flags) and char * virConnSaveTuning(virConnectPtr conn, int flags) which would be fine as separate entry points if someone wanted to embbed them. Of course this fode is 10x easier to write in Python or something else dealing easilly with strings ... 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