Re: [Engine-devel] CPU Pinning @engine

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(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. 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(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 >>>>>>>> >> >