7:55 a.m.
----- Original Message -----
From: "Yaniv Kaul" <ykaul(a)redhat.com>
To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
Cc: "Dan Kenigsberg" <danken(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Wednesday, December 5, 2012 2:45:46 PM
Subject: Re: [Engine-devel] host cpu feature
On 12/05/2012 03:39 PM, Laszlo Hornyak wrote:
>
> ----- Original Message -----
>> From: "Dan Kenigsberg" <danken(a)redhat.com>
>> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>> Cc: "Yaniv Kaul" <ykaul(a)redhat.com>, "engine-devel"
>> <engine-devel(a)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(a)redhat.com>
>>>> To: "Laszlo Hornyak" <lhornyak(a)redhat.com>
>>>> Cc: "engine-devel" <engine-devel(a)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(a)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
You may be right, could you send an URL to that point of the documentation or copy-paste?
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?