[Engine-devel] CPU Pinning @engine

[Miki Kenneth]

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 at redhat.com>
> To: "Ayal Baron" <abaron at redhat.com>
> Cc: engine-devel at 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 at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>