[Engine-devel] CPU Pinning @engine

Mon May 21 09:40:33 UTC 2012

On 21/05/12 12:18, Yaniv Kaul wrote:
> On 05/21/2012 11:53 AM, Doron Fediuck wrote:
>> On 21/05/12 11:16, Yaniv Kaul wrote:
>>> 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).
>> This is a pure speculation. If I'm pinning a specific VM to a specific host, and its vCPUS into specific pCPUs,
>> how can live migration be considered a safe thing? If I pinned to host, this is a violation of my request. Now, let's say
>> I didn't pin to host, but I ask for specific vCPUS pinning into specific pCPUs. For now, there's no guarantee the destination
>> host will have a relevant CPU capacity (maybe even topology), so CPU pinning may not work, which is also a violation of
>> my request. Is live migration really the safe thing to do here??? Why not alert me so I could manually migrate to where I think
>> is better?
>> Having that said, I'm reminding you the somewhere earlier in this thread I wrote we'll make the constraint of cpu pinning
>> allowed only on pinned-to-host VMs configurable, so people who wish to walk on wild side, can give it a go.
> 
> I think the consensus of the thread is that you should allow pin vCPUs to pCPUs even if the VM is not pinned to host.
> If the user wants to ensure it will not migrate, he should mark the VM as non migratable.
> Otherwise, it may migrate, and will succeed - if it can meet  the same pinning requirements on the destination, or fail - and then no harm done.
> If migration succeeds without meeting the pinning requirements on the destination, I see this as a libvirt bug.
> Y.
Basically I already said cpu-pin is allowed for migrative VM's once configuring it.
So basically what you're saying is that if such migration works, while loosing cpu-pin, it's a libvirt bug.
I can live with that. I hope Daniel agrees with you.

> 
>>
>>> Sorry is when you wish you had done so initially.  ;-)
>> In this case, I disagree as this is configurable.
>>
>>> 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
>>>>>>>>
>>
> 


-- 

/d

"The answer, my friend, is blowing in the wind" --Bob Dylan, Blowin' in the Wind (1963)