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