[Engine-devel] CPU Pinning @engine

[Doron Fediuck]

On 24/05/12 10:25, Dor Laor wrote:
> On 05/24/2012 10:02 AM, Ayal Baron wrote:
>> <SNIP>
>>
>>> 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
>>
>> What happens if VM is not pinned to host but the other checkbox with the very long description is checked (i.e. only user initiated migrations), upon startup the system would automatically choose a host but from that point on not migrate unless user chooses to do so?
>>
>> The different combinations of the following leave me feeling that this is over complicated (or presented in a confusing manner):
>> 1. Specific host
>> 2. Run VM on Selected Host
>> 3. Allow VM migration only upon Administrator...
> 
> I'm didn't fully understand the above options - what's the diff between 1 and 2?
> 
> You're right it's all pretty complicated.
> 
> The friendliest thing one can do (but takes time) is a graphical presentation:
> 
> The GUI presents various icons that represents all the host in the cluster (when there are plenty of hosts, it can bunch them together and write the number underneath). When a user selects a pinning string, the GUI automatically shows the group of hosts that match this pinning (removes the ones not relevant).
> 
> Eventually the user can choose whether there are enough matching hosts to allow migration+cpu_pinning or only admin manual migration.
> 
> 
> About the pinning string, it's gets messy defining exclusion (can you exclude several pcups?).
> 
> Again GUI should come to the rescue and you should have a drag and drop graphical tool where you drag vcpus on a group of pcpus.
> 
> I've done a similar thing in a previous company I worked for and it was really simple and neat for the user.
> 

I agree with Dor.
Let's keep it simple; this feature handles CPU pinning only.
Anything related to migration should be determined by the various existing _host_ pinning options, which should already be there.
>From CPU-pinning point of view, migration is failed by libvirt if destination topology cannot host such pinning policy (we verified it).

I also agree UI will do magic here, but that's for next phases.

>>
>> a. Is 1 supposed to be "Preferred host" ? i.e. should run on it if possible but not mandate it (and auto migrate is enabled and also probably also auto migrate back to it when possible)
>> b. if using 1 + 2 - Vm is pinned to host? ("Run VM on Selected Host" is the wrong terminology imo)
>> c. if using 1 + 3 - VM preferred host is specified (could start on different host in case of pressure) and no auto migrate (if started on non preferred host then will not auto-migrate to preferred host)
>> d. ~1 (not specific host) + 3 - start wherever but only user initiated migrations are allowed.
>> e. I assume 2+3 cannot coexist as well as ~1+2
>> f. ~1 + ~3 - Regular VM (system chooses where to run it and it auto migrates).
> 
> 
> 
> 
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 


-- 

/d

"Air conditioned environment - Do NOT open Windows!"