[Libvir] The problem of the definition of tuning informations

I promised that mail for the beginning of the week but I still have a very hard time to try to formulate a good plan of action, I'm still stuck in a dilemna, see below. What is it? ----------- I think tuning informations are that set of parameters associated to a domain or a host, which are not stricly needed to get the domain(s) working but improve their runtime behaviour. To me this includes: - scheduling parameters the scope may be host/hypervisor/domain - vcpu affinity i.e. to which set of physical CPU each of the vcpu may be bound - and possibly others ... The problem: ------------ People would like to associate those to the XML domain informations, the goal being to be able to restore those informations when a domain (re-)starts. I have been objecting it so far because, I think those informations don't have the same lifetime and scope as the other domain informations saved in the XML. Since they are not needed to start the domain, and that once the domain is started the existing domain API can be used to change those informations, it is better to keep them separate. However I got objections from David Lutterkort [1], Jim Fehlig [2], and John Levon [3] plus of course the initial request for it from Tatsuro Enokura (and the Fujistu people in general) [4] The problem to me comes from 2 things: 1/ storing tuning informations in domains descriptions is not sufficient 2/ if we store them there we also need to always save them when exporting the XML domain file 2/ is fairly important to avoid a lot of problems as we have experienced before for example with console informations. If the input for virsh create gets different from the output of dumpxml, a lot of rather annoying things happen in practice, it certainly generate confusion. So we really need to output those tuning data if we put them in. Also I strongly believe in 1/, i.e. tuning informations are cross domain and they are vey likely to change fast as soon as the management applications will get deployed, but even in relatively small deployment the tuning is rather a per host informations, which may depend on the current workload of the machine. I don't believe in tuning being loaded at create time and never changing later. Even in my own very basic usage that doesn't match my use which lead me to load and stop domain on demand for short period of time. My opinion: ----------- We need better tools, even for simple use case to be able to save an existing tuning for a domain or a full machine, and reload it when needed. This is IMHO better done on top of the existing API which already have the entry points to implement them. My idea is to provide tuning commands in virsh [5]. If you implement tuning both at creation time and in the tool, this mean you either make them different in which case you have no coherency between what you say when you create a domain or save its config and what you do at the virsh level. If you don't make it different (for example trying to use the same kind of XML syntax), then you need code for doing this both in the tool and in the library itself, or you export as a new API the tuning load and save. Exporting as a parallel API what we have already for scheduling and VCPU affinity makes the API more complex, and less coherent. I don't want to force the decision one way or another, it is probable I missed something, but I don't think adding tuning informations to the domain configuration file to be really that convenient, I could be done better, and with less associated problems by keeping those separate. Daniel [1] https://www.redhat.com/archives/libvir-list/2007-October/msg00250.html [2] https://www.redhat.com/archives/libvir-list/2007-November/msg00003.html [3] https://www.redhat.com/archives/libvir-list/2007-October/msg00046.html [4] https://www.redhat.com/archives/libvir-list/2007-October/msg00221.html [5] https://www.redhat.com/archives/libvir-list/2007-October/msg00245.html -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/