Hi, Daniel Daniel Veillard wrote: > 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. I agree that it does not necessary weight/cap information on boot Also, I agree that these informations stores as tuning information not XML format. Since these informations lifetime is different. I hope two things to consider 1) tuning infoamations can set on boot 2) tuning informations can set via libvirt API on domain shutoff. Tatsuro Enokura -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list