[Libvir] The problem of the definition of tuning informations
fj7716hz at aa.jp.fujitsu.com
Thu Nov 15 02:41:41 UTC 2007
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
> 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 , Jim Fehlig ,
> and John Levon  plus of course the initial request for it from
> Tatsuro Enokura (and the Fujistu people in general) 
> 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 . 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.
More information about the libvir-list