[Libvir] The problem of the definition of tuning informations

[Tatsuro Enokura]

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