Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu> I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks. Thanks, - Christy
On 06/27/2014 06:27 AM, Christy Perez wrote:
Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu> Affinity also support ?
VCPU pinning to some physical CPU？
I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks.
Thanks,
- Christy
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
On Fri, 2014-06-27 at 08:41 +0800, Sheldon wrote:
On 06/27/2014 06:27 AM, Christy Perez wrote:
Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu> Affinity also support ?
VCPU pinning to some physical Yes, all those should be added as well. The complexity in adding the right combinations, per-system feature validation, kinds of errors they might generate, etc., made me think that for now, it might be better to start with a smaller, more commonly used feature, and then add the others piece-wise in the same way. A more agile approach.
I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks.
Thanks,
- Christy
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 06/27/2014 10:23 PM, Christy Perez wrote:
On Fri, 2014-06-27 at 08:41 +0800, Sheldon wrote:
On 06/27/2014 06:27 AM, Christy Perez wrote:
Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu> Affinity also support ?
VCPU pinning to some physical Yes, all those should be added as well. The complexity in adding the right combinations, per-system feature validation, kinds of errors they might generate, etc., made me think that for now, it might be better to start with a smaller, more commonly used feature, and then add the others piece-wise in the same way. A more agile approach.
agree.
I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks.
Thanks,
- Christy
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Thanks and best regards! Sheldon Feng(冯少合)<shaohef@linux.vnet.ibm.com> IBM Linux Technology Center
On Sat, 2014-06-28 at 16:35 +0800, Sheldon wrote:
On 06/27/2014 10:23 PM, Christy Perez wrote:
On Fri, 2014-06-27 at 08:41 +0800, Sheldon wrote:
On 06/27/2014 06:27 AM, Christy Perez wrote:
Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu> Affinity also support ?
VCPU pinning to some physical Yes, all those should be added as well. The complexity in adding the right combinations, per-system feature validation, kinds of errors they might generate, etc., made me think that for now, it might be better to start with a smaller, more commonly used feature, and then add the others piece-wise in the same way. A more agile approach.
agree.
+1
I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks.
Thanks,
- Christy
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On Thu, 2014-06-26 at 17:27 -0500, Christy Perez wrote:
Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu>
I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks.
Christy, I agree with you that adding this support only to templates is simpler, but looking for the functionality itself (and for the user point of view), it's necessary edit this information on the already created guests, also. So, for me, this work have two parts: 1) add the support on templates; and 2) add the support on guest edit screen. You can send only one patch set with the two parts or send each part in separated threads to make it available quickly on templates, at least. My 2 cents!
Thanks,
- Christy
Best regards, Paulo.
On 06/26/2014 07:27 PM, Christy Perez wrote:
Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu>
I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks.
According to the reference https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2-817d-4... There are some restrictions to configure SMT what can not be intuitive for a Kimchi user. So I like the idea to keep it only on templates (at least for while) and see how Kimchi users react on that. We will need to properly add a logic to get the best pairs of cores/threads according to the vcpus number. In my mind, we should only add a check box on Template edit: "Enable SMT" if checked Kimchi knows what it needs to do when creating a VM
Thanks,
- Christy
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 07/01/2014 11:32 PM, Aline Manera wrote:
On 06/26/2014 07:27 PM, Christy Perez wrote:
Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu>
I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks.
According to the reference https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2-817d-4...
There are some restrictions to configure SMT what can not be intuitive for a Kimchi user.
So I like the idea to keep it only on templates (at least for while) and see how Kimchi users react on that. We will need to properly add a logic to get the best pairs of cores/threads according to the vcpus number.
In my mind, we should only add a check box on Template edit: "Enable SMT" if checked Kimchi knows what it needs to do when creating a VM
Thanks,
- Christy
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 07/01/2014 11:32 PM, Aline Manera wrote:
On 06/26/2014 07:27 PM, Christy Perez wrote:
Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu>
I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks.
According to the reference https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2-817d-4...
There are some restrictions to configure SMT what can not be intuitive for a Kimchi user.
So I like the idea to keep it only on templates (at least for while) and see how Kimchi users react on that. We will need to properly add a logic to get the best pairs of cores/threads according to the vcpus number.
In my mind, we should only add a check box on Template edit: "Enable SMT" if checked Kimchi knows what it needs to do when creating a VM
I think we can do something better! In addition to the check box, we can provide a combo box with the available choices for SMT. These values are static defined as SMT=1, SMT=2, SMT=4, or SMT=8. So, when the user select the SMT check box, the combo box make enable to user select one of these 4 options. Then, at the moment to write the XML, Kimchi backend do math to create the topology entry based on the SMT value and the number of processors defined. For example, if user sets a template to have 8 processors and SMT=4, the backend must create following entry on the XML file: <vcpu>8</vcpu> <cpu> <topology sockets='1' cores='2' threads='4'/> </cpu> That's my 3 cents. Thanks and best regards, Paulo Vital
On 07/01/2014 11:32 PM, Aline Manera wrote:
On 06/26/2014 07:27 PM, Christy Perez wrote:
Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu>
I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks.
According to the reference https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2-817d-4...
There are some restrictions to configure SMT what can not be intuitive for a Kimchi user.
So I like the idea to keep it only on templates (at least for while) and see how Kimchi users react on that. We will need to properly add a logic to get the best pairs of cores/threads according to the vcpus number.
In my mind, we should only add a check box on Template edit: "Enable SMT" if checked Kimchi knows what it needs to do when creating a VM
I'm fine with only on template edit. In the future, though, hopefully we'll be adding maybe an "Advanced" sub-panel when creating templates
On Wed, 2014-07-02 at 09:50 -0300, Paulo Ricardo Paz Vital wrote: that lets users do things like this?
I think we can do something better! In addition to the check box, we can provide a combo box with the available choices for SMT. These values are static defined as SMT=1, SMT=2, SMT=4, or SMT=8.
So, when the user select the SMT check box, the combo box make enable to user select one of these 4 options. Then, at the moment to write the XML, Kimchi backend do math to create the topology entry based on the SMT value and the number of processors defined.
For example, if user sets a template to have 8 processors and SMT=4, the backend must create following entry on the XML file:
What if they set 7 processors? We could disable the SMT checkboxes if their CPU # wasn't a multiple of anything. So we'll probably have to come up with very good help/hint text for this. Or, if they select SMT, the CPU box becomes un-editable, and then selecting one of the SMT options, the CPU count (in the un-editable field) is updated so that they can understand what VCPU count they'll end up before they click OK.
<vcpu>8</vcpu> <cpu> <topology sockets='1' cores='2' threads='4'/> </cpu>
That's my 3 cents. Thanks and best regards, Paulo Vital
On 07/02/2014 11:30 AM, Christy Perez wrote:
On 07/01/2014 11:32 PM, Aline Manera wrote:
On 06/26/2014 07:27 PM, Christy Perez wrote:
Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu>
I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks.
According to the reference https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2-817d-4...
There are some restrictions to configure SMT what can not be intuitive for a Kimchi user.
So I like the idea to keep it only on templates (at least for while) and see how Kimchi users react on that. We will need to properly add a logic to get the best pairs of cores/threads according to the vcpus number.
In my mind, we should only add a check box on Template edit: "Enable SMT" if checked Kimchi knows what it needs to do when creating a VM
I'm fine with only on template edit. In the future, though, hopefully we'll be adding maybe an "Advanced" sub-panel when creating templates
On Wed, 2014-07-02 at 09:50 -0300, Paulo Ricardo Paz Vital wrote: that lets users do things like this?
Agree. This kind of info may be too complex for a Kimchi user I'd say to start only with the check box and in future (after getting feedbacks) add more details in the "Advanced" panel
I think we can do something better! In addition to the check box, we can provide a combo box with the available choices for SMT. These values are static defined as SMT=1, SMT=2, SMT=4, or SMT=8.
So, when the user select the SMT check box, the combo box make enable to user select one of these 4 options. Then, at the moment to write the XML, Kimchi backend do math to create the topology entry based on the SMT value and the number of processors defined.
For example, if user sets a template to have 8 processors and SMT=4, the backend must create following entry on the XML file:
What if they set 7 processors? We could disable the SMT checkboxes if their CPU # wasn't a multiple of anything. So we'll probably have to come up with very good help/hint text for this.
Or, if they select SMT, the CPU box becomes un-editable, and then selecting one of the SMT options, the CPU count (in the un-editable field) is updated so that they can understand what VCPU count they'll end up before they click OK.
<vcpu>8</vcpu> <cpu> <topology sockets='1' cores='2' threads='4'/> </cpu>
That's my 3 cents. Thanks and best regards, Paulo Vital
Christy, I added SMT support to 1.3 sprint 1. Let me know if it works for you, otherwise I move it to sprint 2 https://github.com/kimchi-project/kimchi/wiki/Todo-1.3 On 07/03/2014 10:26 AM, Aline Manera wrote:
On 07/02/2014 11:30 AM, Christy Perez wrote:
On 07/01/2014 11:32 PM, Aline Manera wrote:
On 06/26/2014 07:27 PM, Christy Perez wrote:
Quick poll for adding support for <cpu> <topology sockets='1' cores='2' threads='1'/> </cpu>
I know it would be nice to let users add it on a per-vm basis, but maybe it might be something that we'd rather just leave in the template only. Having it in the template only seems simpler when thinking about UI design, imo, but I'd love to hear what everyone else thinks.
According to the reference https://www.ibm.com/developerworks/community/blogs/fe313521-2e95-46f2-817d-4...
There are some restrictions to configure SMT what can not be intuitive for a Kimchi user.
So I like the idea to keep it only on templates (at least for while) and see how Kimchi users react on that. We will need to properly add a logic to get the best pairs of cores/threads according to the vcpus number.
In my mind, we should only add a check box on Template edit: "Enable SMT" if checked Kimchi knows what it needs to do when creating a VM
I'm fine with only on template edit. In the future, though, hopefully we'll be adding maybe an "Advanced" sub-panel when creating templates
On Wed, 2014-07-02 at 09:50 -0300, Paulo Ricardo Paz Vital wrote: that lets users do things like this?
Agree. This kind of info may be too complex for a Kimchi user I'd say to start only with the check box and in future (after getting feedbacks) add more details in the "Advanced" panel
I think we can do something better! In addition to the check box, we can provide a combo box with the available choices for SMT. These values are static defined as SMT=1, SMT=2, SMT=4, or SMT=8.
So, when the user select the SMT check box, the combo box make enable to user select one of these 4 options. Then, at the moment to write the XML, Kimchi backend do math to create the topology entry based on the SMT value and the number of processors defined.
For example, if user sets a template to have 8 processors and SMT=4, the backend must create following entry on the XML file:
What if they set 7 processors? We could disable the SMT checkboxes if their CPU # wasn't a multiple of anything. So we'll probably have to come up with very good help/hint text for this.
Or, if they select SMT, the CPU box becomes un-editable, and then selecting one of the SMT options, the CPU count (in the un-editable field) is updated so that they can understand what VCPU count they'll end up before they click OK.
<vcpu>8</vcpu> <cpu> <topology sockets='1' cores='2' threads='4'/> </cpu>
That's my 3 cents. Thanks and best regards, Paulo Vital
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (4)
-
Aline Manera -
Christy Perez -
Paulo Ricardo Paz Vital -
Sheldon