----- Original Message -----
From: "Yaniv Kaul" <ykaul(a)redhat.com>
To: "Andrew Cathrow" <acathrow(a)redhat.com>
Sent: Thursday, December 29, 2011 9:47:24 AM
Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
On 12/29/2011 04:34 PM, Andrew Cathrow wrote:
> ----- Original Message -----
>> From: "Itamar Heim"<iheim(a)redhat.com>
>> To: "Miki Kenneth"<mkenneth(a)redhat.com>
>> Cc: engine-devel(a)ovirt.org
>> Sent: Thursday, December 29, 2011 5:41:41 AM
>> Subject: Re: [Engine-devel] SPM Priority Design - Wiki Page
>> On 12/27/2011 05:22 PM, Miki Kenneth wrote:
>>> Few points:
>>> - From requirement perspective - 0-10 scale is OK too.
>>> - There is an RFE to allow manual SPM selection, let's make sure
>>> that we clarify how we do that in the scenarios.
>>> - There is a case were all Hosts are set as "no SPM" (-1), user
>>> should be notify (on the last host?)
> I don't agree with/understand the requirements
> - Enable setting a priority between -1 and 100 for a host (100 is
> the highest, -1 means never to choose this host).
> - When SPM selection process takes place, use the SPM priority to
> select an SPM.
> - Default for upgrading ovirt will be 50.
> Here we are asking the user to define priorities for the SPM
> selection. A user should be able to influence the selection but
> the actual choice should come down to runtime status.
> If Host A us running 100 VMs and host B is running 50 then it seems
> more efficient for B to be the SPM rather than A
> If Host C has multiple storage paths to the LUN then it seems a
> better fit than host B that has only one path.
> We need to step back and review the requirements here.
> Today SPM selection is random, that certainly needs to change but a
> user defining priorities is overly complex and won't solve the
> runtime selection issue.
> We need to start by defining an algorithm for selecting the SPM
> independent of user input.
> At selection time I'd suggest that we at least need to consider
> number of paths to the storage (for block based) number of VMs on
> that host, perhaps #cores?
Paths to which storage domain? the master? all? on average?
Do you prefer 2x10Gb iSCSI connection, or 4x1Gb?
- What about available bandwidth to the storage (assuming it may be
capped and compete with VM IO traffic) ?
Yep, exactly - we need to use these kind of inputs into the algorithm and these can change
hence the need to do this more dynamically rather than user selection which is invariably
> Perhaps we should dynamically create a score for a host that takes
> these factors into account, each may get higher rating - eg. maybe
> # storage paths is more important that # cores ?
This is why I've suggested High(8)-Med(5)-Low(2) and add dynamically
system scoring, with whatever params we get to eventually. 'Never'
be 0, 'Always' could be '10'.
Yep, the big change that I'm suggesting is that these scores are only an input to the
algorithm not the whole basis for selection.
> On top of this we can add some user defined preference that plays
> into the score. For example a user can say "this host can NEVER be
> an SPM" or can set a preference - eg. "Preferred SPM" or perhaps
> even "always SPM"
> This algorithm would apply for automated selection of SPMs but a
> user should be allowed to override this and at runtime say "make
> this node the SPM now"
>> SPM is DC level, not cluster level.
>>> - Need to be able to view in the GUI:
>>> - the SPM priority for all Hosts, on the GRID?
>> isn't this cluttering the hosts grid? general subtab maybe?
>> Engine-devel mailing list
> Engine-devel mailing list