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(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
/d
"Air conditioned environment - Do NOT open Windows!"