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
>> [email protected]
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
--
/d
"Air conditioned environment - Do NOT open Windows!"
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
