On 21/05/12 12:40, Doron Fediuck wrote: > 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"<[email protected]> >>>>>>>>> To: [email protected] >>>>>>>>> Cc: [email protected] >>>>>>>>> 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. >
Design updated, so pinning is not blocked, unless user will block it (pin to host, etc). UI will be updated shortly. Please review- http://www.ovirt.org/wiki/Features/Design/cpu-pinning >> >>> >>>> 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"<[email protected]> >>>>>>>>>>>>> To: [email protected] >>>>>>>>>>>>> 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 >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Engine-devel mailing list >>>>>>>>>>>> [email protected] >>>>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>> -- >>>>>>>>> >>>>>>>>> /d >>>>>>>>> >>>>>>>>> Never say "OOPS!" always say "Ah, Interesting!" >>>>>>>>> _______________________________________________ >>>>>>>>> Engine-devel mailing list >>>>>>>>> [email protected] >>>>>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>>>>>> >>> >> > > -- /d "Hi, my name is Any Key. Please don't hit me!" _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
