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