[Engine-devel] CPU Pinning @engine

[Yaniv Kaul]

On 05/21/2012 11:08 AM, Doron Fediuck wrote:
> On 21/05/12 11:01, Dor Laor wrote:
>> On 05/21/2012 10:58 AM, Doron Fediuck wrote:
>>> On 21/05/12 01:45, Andrew Cathrow wrote:
>>>>
>>>> ----- Original Message -----
>>>>> From: "Doron Fediuck"<dfediuck at redhat.com>
>>>>> To: dlaor at redhat.com
>>>>> Cc: engine-devel at ovirt.org
>>>>> Sent: Sunday, May 20, 2012 5:49:08 PM
>>>>> Subject: Re: [Engine-devel] CPU Pinning @engine
>>>>>
>>>>> On 20/05/12 21:41, Dor Laor wrote:
>>>>>> On 05/17/2012 11:15 PM, Doron Fediuck wrote:
>>>>>>> On 17/05/12 20:28, Ayal Baron wrote:
>>>>>>>> "Live migration will not be supported for such VM's."
>>>>>>>>
>>>>>>>> Migration will work on homogeneous clusters so this should not be
>>>>>>>> enforced (not limited to VMs which are pinned to host) just give
>>>>>>>> a warning.
>>>>>>>>
>>>>>>> I agree, but if we wish to ping vCPUx to pCPUy in host a, we
>>>>>>> cannot ensure to have the same in host b,
>>>>>>> since it may have pCPUy too busy, so performance will degrade.
>>>>>>> Also, I hope you saw my general comment
>>>>>> Performance may degrade on any migration to loaded host regardless
>>>>>> of pinning.
>>>>>>
>>>>>> There is not need to forbid migration. Instead, the SLA assurance
>>>>>> policy should verify the dedicated resources and match the target
>>>>>> w/ the guarantee and decide according to this.
>>>>>>
>>>>> Thanks for the input.
>>>>> We may start with migration blocked in a configurable manner, so
>>>>> people who wish migrate to work
>>>>> will simply set the relevant configuration key.
>>>>> As for looking for a matched CPU, will add it as p2.
>>>> We shouldn't block migration
>>>> If a user wants to not migrate a cpu pinned VM then let them use the non-migratable flag in the UI.
>>>>
>>> We're not blocking migration, we're allowing pinning (for now) only for non-migrative VM's.
>>> For p2 we'll verify destination host has the relevant pinning capacity, which will allow
>>> pinning for migrative VM's as well.
>>
>> IMHO the order should be the opposite - if the user likes to migrate a pinned VM, let him (you can pop some message if you like).
> I'll check it with UI guys (AFAIK engine UI has no pop-ups).
> Also, I prefer safe than sorry. So start with a safe working pinning for pinned-to-host VMs, and then push the envelope.

Safe is letting the user migrate. It may or may not succeed (I'd worry 
it may put a host into Error state - I hope we've removed this state).
Sorry is when you wish you had done so initially.  ;-)
Y.


>
>>>>>>> about starting with a humble solution and gradually improving. In
>>>>>>> this context (auto)numa can help us,
>>>>>>> so we better do numa than handle migration for basic mode, risking
>>>>>>> performance issues.
>>>>>>>
>>>>>>>> ----- Original Message -----
>>>>>>>>> From: "Doron Fediuck"<dfediuck at redhat.com>
>>>>>>>>> To: engine-devel at ovirt.org
>>>>>>>>> Sent: Thursday, May 17, 2012 2:42:46 PM
>>>>>>>>> Subject: [Engine-devel] CPU Pinning @engine
>>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>> Currently the VDSM has a CPU pinning hook.
>>>>>>>>> We'd like to add better support of it into the engine itself.
>>>>>>>>> Here's a design draft to cover it:
>>>>>>>>> http://www.ovirt.org/wiki/Features/Design/cpu-pinning
>>>>>>>>>
>>>>>>>>> Please review and comment if needed.
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> -- 
>>>>>>>>>
>>>>>>>>> /d
>>>>>>>>>
>>>>>>>>> Never say "OOPS!" always say "Ah, Interesting!"
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Engine-devel mailing list
>>>>>>>> Engine-devel at ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>
>>>>>
>>>>> -- 
>>>>>
>>>>> /d
>>>>>
>>>>> Never say "OOPS!" always say "Ah, Interesting!"
>>>>> _______________________________________________
>>>>> Engine-devel mailing list
>>>>> Engine-devel at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>
>>>
>