[Libvir] The problem of the definition of tuning informations

beth kon eak at us.ibm.com
Tue Nov 13 16:51:09 UTC 2007


beth kon wrote:

> Daniel Veillard wrote:
>
>> On Thu, Nov 08, 2007 at 02:00:10PM -0600, Ryan Harper wrote:
>>  
>>
>>> * 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.
>>>   
>>
>>
>>  yes, I understand and that's why I agreed to add the cpuset information
>> at that point it's more than tunning because it may be irreversible 
>> for the
>> lifetime of the domain, so this really should be in the XML. I'm not
>> suggesting to go back about 'cpu affinity' i.e. to which physical CPUs
>> a domain should be bound, but 'vcpu affinity' i.e. then how the virtual
>> CPUs of the domain are mapped onto that cpu set, that can change
>> dynamically without (serious) performance penalty.
>>  
>>
>>> 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.
>>>   
>>
>>
>>  My point is that you don't need the tuning informations to create the
>> domain, if you need them it's not tuning. When you say you want to
>> merge them, do you want this to create the domain ? It should not
>> be necessary (or I take a counter example that would help me), right ?
>>  
>>
> It seems to me that the only reason cpuset information is being 
> treated as more than tuning is due to an artifact of Xen (i.e., it 
> must be specified at domain creation). For KVM, for example, I believe 
> this can be specified after domain creation.
>
> From a libvirt perspective, I think the XML config/tuning split should 
> be hypervisor-neutral, and based solely on what is required to get a 
> domain running (ignoring performance):
>
> 1) XML contains arguments absolutely needed to start a domain in any 
> hypervisor. This could be thought of as the minimum requirements for 
> starting a domin.
>
> 2) Tuning information contains arguments that affect performance, and 
> may be changed.
>
> When a domain is started, the caller can specify a minimal start (XML 
> only) or a tuned start (XML plus tuning). Lower level libvirt code 
> would understand the specifics of the hypervisor well enough to know 
> whether it had to include some of the tuning information at domain 
> creation time.

Daniel and I have been discussing this a bit on IRC, so I will dump that 
information on the list... (correct me if I misstate something here, 
Daniel :-)

Daniel wants to have the xml contain all parameters that must be 
specified at domain creation in order to achieve proper function, and 
cannot be tuned later. I agree this is a reasonable definition. In this 
case, cpuset would need to be in the xml.

My concern is that currently Xen will fail a domain create request if 
the cpu is out of range with the error "invalid argument", so the user 
will not have enough information to correct the problem in the xml and 
try again. We can pursue getting a more explicit error message from 
Xen.  Or Xen could ignore the cpuset and start the domain, perhaps with 
a warning message.

My thinking was that ideally it might be good to have libvirt provide 2 
start methods - minimal and tuned, but Daniel thinks it is not worth the 
complexity. It should be up to the user to correct issues in the xml and 
try again.

>
>> Daniel
>>
>>  
>>
>
>


-- 
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak at us.ibm.com




More information about the libvir-list mailing list