[Engine-devel] host cpu feature

[Yaniv Kaul]

On 12/05/2012 03:39 PM, Laszlo Hornyak wrote:
>
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken at redhat.com>
>> To: "Laszlo Hornyak" <lhornyak at redhat.com>
>> Cc: "Yaniv Kaul" <ykaul at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
>> Sent: Wednesday, December 5, 2012 1:55:19 PM
>> Subject: Re: [Engine-devel] host cpu feature
>>
>> On Wed, Dec 05, 2012 at 06:46:09AM -0500, Laszlo Hornyak wrote:
>>>
>>> ----- Original Message -----
>>>> From: "Yaniv Kaul" <ykaul at redhat.com>
>>>> To: "Laszlo Hornyak" <lhornyak at redhat.com>
>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
>>>> Sent: Wednesday, December 5, 2012 12:23:47 PM
>>>> Subject: Re: [Engine-devel] host cpu feature
>>>>
>>>> On 12/05/2012 12:32 PM, Laszlo Hornyak wrote:
>>>>> Hi,
>>>>>
>>>>> CPU-Host support allows the virtual machines to see and utilize
>>>>> the
>>>>> host's CPU flags, this enables better performance in VM's, at
>>>>> the
>>>>> price of worse portablity.
>>>>>
>>>>> http://www.ovirt.org/Features/Cpu-host_Support
>>>>>
>>>>> Your feedback is welcome!
>>>>>
>>>>> Thank you,
>>>>> Laszlo
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>> - I assume that when you allow migration, you'd use host-model?
>>>> This
>>>> is
>>>> not clear from the design. It seems like we VDSM developers can
>>>> choose
>>>> to use either this or passthrough, while in practice we should
>>>> support both.
>> I join Kaul's question: it is an ovirt-level question whether
>> hostPassthrough or hostModel or both should be supported. It should
>> not
>> be a unilateral vdsm decision.
> Ah, possibly misunderstanding, I did not mean that VDSM should decide whether to use host-passthrough or host-model. The engine should decide.
> I meant _you_ should decide which version of vdsm api modification do you want :)
>
>>> If AllowMigrateCPUHost is set to true (in case you have the same
>>> cpu model everywhere in your DC) migration of such hsots will be
>>> enabled. Otherwise it will not be enabled.
>> What is the breadth of AllowMigrateCPUHost? Engine wide? Per DC? Per
>> cluster?
> I thought of eninge-wide. The of course you can have different models in two different DC, but they should be unique in one.
> We can add this to DC or cluster level, imho it would be just another checkbox on the UI that most users would not use.
>
>> I favor the latter; a user may have a cluster of exact-same hosts,
>> where
>> hostcpu migration is allowed, and other cluster where it is forbiden.
>>
>> The nice thing about hostModel (unlike hostPassthrough) is that once
>> we
>> created the VM we can migrate it to stronger hosts, and back to the
>> original host. I suppose that it complicates the scheduler.
> Yes with host-model you get the features that libvirt handles. In such cases the engine could decide, if you want this functionality. Well the scheduler architecture is just being reinvented.
>
> For the host-passthrough, I think the AllowMigrateCPUHost configuration option would be a simple decision for the administrator: set it to true if all hosts are uniform. If it is not set to true, then we will not allow migration of such VMs.

That's not what I understood from libvirt's documentation. I understood 
that if you want host+migration, you need to use host-model. Otherwise - 
host-passthrough.
Y.

>
>>>> - I'm still convinced and commented on both relevat oVirt and
>>>> libvirt
>>>> BZs that we need to add x2apic support to the CPU, regardless of
>>>> what
>>>> the host CPU exposes.
>>>> AFAIK, the KVM developers agree with me.
>>> Not quite sure how is this related... could you send some URL's for
>>> the bugreports?