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(a)redhat.com>
>>>>>> To: dlaor(a)redhat.com
>>>>>> Cc: engine-devel(a)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.
> 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(a)redhat.com>
>>>>>>>>>> To: engine-devel(a)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(a)ovirt.org
>>>>>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Engine-devel mailing list
>>>>>>>>> Engine-devel(a)ovirt.org
>>>>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>> --
>>>>>>
>>>>>> /d
>>>>>>
>>>>>> Never say "OOPS!" always say "Ah,
Interesting!"
>>>>>> _______________________________________________
>>>>>> Engine-devel mailing list
>>>>>> Engine-devel(a)ovirt.org
>>>>>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>>>>>