11:24 a.m.
This is good feedback - unrelated to the vCPU pining discussion tough.
Few points:
1. Migration options are relevant only when specific host is selected.
2. "run on selected host" - means pin ONLY to this host, if unavailable, the VM
won't run, and no migration will occur.
3. "allow migration" - means admin can manually migrate this VM to any other
host.
AFAIK, no logic for migration back currently exists.
Miki
----- Original Message -----
From: "Dor Laor" <dlaor(a)redhat.com>
To: "Ayal Baron" <abaron(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Thursday, May 24, 2012 10:25:35 AM
Subject: Re: [Engine-devel] CPU Pinning @engine
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.
>
> 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
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel