[Libvir] The problem of the definition of tuning informations

[Ryan Harper]

* Daniel Veillard <veillard at redhat.com> [2007-11-08 10:08]:
>   I promised that mail for the beginning of the week but I still have
> 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.

For at least (maybe only) Xen NUMA systems, the application of "tuning"
information after a domain is started does not achieve the same affect
as including the information during the initial construction of the
domain.  In particular, Xen needs to know which physical cpus are being
used to determine which cpus it from which numanode it will allocate
memory.  Adjusting affinity after the domain has allocated memory
doesn't allow libvirt or any management app to control from which node
domains pull memory.

I don't have any objection to separating "tuning" information as long as
we have the ability to merge permanent domain parameters with its
"tuning" information prior to domain construction.

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-9253   T/L: 678-9253
ryanh at us.ibm.com