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" <[email protected]> > To: "Ayal Baron" <[email protected]> > Cc: [email protected] > 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 > > [email protected] > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ > Engine-devel mailing list > [email protected] > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
