[RFC] Allow user to specify max virtual cpus in template and guest
Current State ------------- Currently we have the following values defined for a KVM guest created by Kimchi: <vcpu placement='static' current='4'>252</vcpu> <cpu> <topology sockets='63' cores='2' threads='2'/> </cpu> User specifies the processor topology (optional) and the number of virtual CPUs and sockets are calculated by Kimchi based on maximum supported by the hypervisor (varies with distro) this way: maximum number of virtual cpus supported = 255 (taken from hypervisor) processor topology: cores=2 , threads=2 (optionally specified by user) number of virtual cpus per socket: cores * threads = 4 (from topology) maximum number of sockets guest can have = int(255/4) = 63 maximum number of virtual cpus guest can use = 4 * 63 = 252 Proposal -------- Allow user to specify the maximum number of virtual cpus for a template or guest (when this one is offline - not running). Changes required ---------------- 1) Backend A) Add "maxvcpus" optional field to both template and guest APIs Restrictions to be implemented on this value: - must be a positive integer - must be a multiple of (cores * threads) - must be less than or equal the maximum number of virtual cpus supported by hypervisor If not specified, the default value for maxvcpus will be the equivalent to one socket (that is, core * threads). B) Change the way number of sockets is calculated: maximum number of virtual cpus supported = 255 (taken from hypervisor) topology: cores=2 , threads=2 (specified by user) maximum number of virtual cpus guest can use = 100 (specified by user) number of virtual cpus per socket: cores * threads = 4 (from topology) maximum number of sockets guest can have = int(100/4) = 25 maximum number of virtual cpus guest can use = 4 * 25 = 100 That would result in: <vcpu placement='static' current='4'>100</vcpu> <cpu> <topology sockets='25' cores='2' threads='2'/> </cpu> C) Update/Add unit tests 2) Frontend A) Edit Template, at "Processor" tab: - change the current "CPU number" field to a -[]+ input field (increase/decrease) - add a new -[]+ input field "Max CPU number" (increase/decrease) for user input of "max virtual CPUs". Restrictions from 1.A) apply here. Despite it's in a different place, we may use a "More Options" artifact similar to the one proposed by Rodrigo Trujillo at "[RFC][Kimchi] Guest Max memory setup and update", to keep the same format. B) Edit Guest, at "General" tab: - add a new -[]+ input field "Max CPUs" (increase/decrease in terms of core * threads) for user input of "max virtual CPUs". This new field is only enabled if guest is not running. Restrictions from 1.A) apply here. Let me know your thoughts. Thanks, -- Lucio Correia Software Engineer IBM LTC Brazil
+1 On 01/13/2016 03:48 PM, Lucio Correia wrote:
Current State ------------- Currently we have the following values defined for a KVM guest created by Kimchi:
<vcpu placement='static' current='4'>252</vcpu>
<cpu> <topology sockets='63' cores='2' threads='2'/> </cpu>
User specifies the processor topology (optional) and the number of virtual CPUs and sockets are calculated by Kimchi based on maximum supported by the hypervisor (varies with distro) this way:
maximum number of virtual cpus supported = 255 (taken from hypervisor) processor topology: cores=2 , threads=2 (optionally specified by user) number of virtual cpus per socket: cores * threads = 4 (from topology) maximum number of sockets guest can have = int(255/4) = 63 maximum number of virtual cpus guest can use = 4 * 63 = 252
Proposal -------- Allow user to specify the maximum number of virtual cpus for a template or guest (when this one is offline - not running).
Changes required ---------------- 1) Backend
A) Add "maxvcpus" optional field to both template and guest APIs Restrictions to be implemented on this value: - must be a positive integer - must be a multiple of (cores * threads) - must be less than or equal the maximum number of virtual cpus supported by hypervisor
If not specified, the default value for maxvcpus will be the equivalent to one socket (that is, core * threads).
B) Change the way number of sockets is calculated: maximum number of virtual cpus supported = 255 (taken from hypervisor) topology: cores=2 , threads=2 (specified by user) maximum number of virtual cpus guest can use = 100 (specified by user) number of virtual cpus per socket: cores * threads = 4 (from topology) maximum number of sockets guest can have = int(100/4) = 25 maximum number of virtual cpus guest can use = 4 * 25 = 100
That would result in: <vcpu placement='static' current='4'>100</vcpu>
<cpu> <topology sockets='25' cores='2' threads='2'/> </cpu>
C) Update/Add unit tests
2) Frontend
A) Edit Template, at "Processor" tab: - change the current "CPU number" field to a -[]+ input field (increase/decrease) - add a new -[]+ input field "Max CPU number" (increase/decrease) for user input of "max virtual CPUs". Restrictions from 1.A) apply here.
Despite it's in a different place, we may use a "More Options" artifact similar to the one proposed by Rodrigo Trujillo at "[RFC][Kimchi] Guest Max memory setup and update", to keep the same format.
B) Edit Guest, at "General" tab: - add a new -[]+ input field "Max CPUs" (increase/decrease in terms of core * threads) for user input of "max virtual CPUs". This new field is only enabled if guest is not running. Restrictions from 1.A) apply here.
Let me know your thoughts.
Thanks,
Hi, I think this looks great. For the UI, the decrease/increase input we can use the input type "number": http://www.w3schools.com/html/tryit.asp?filename=tryhtml_input_number However we can't change the arrows to + and - signs and in IE and Edge it doesn't show any arrows at all. By default it only support numbers but if the user paste any other character it will fill the max character limit (set with the "max" attribute) with the letter "e". I can validate this on the front-end with the "pattern" attribute and for older browsers that don't support it I could put a regex on it. This table shows the current browser support of it: http://caniuse.com/#feat=input-number. I think there are some other known issues with Firefox older than 28 and ESR that are not covered within this list. Based on the back-end specification I think we can mix some of the html5 native attributes with JavaScript to perform the form validation on the front-end. This is the JavaScript spec for this input type: http://www.w3schools.com/jsref/dom_obj_number.asp We could get some values from the back-end and set the attributes on the front-end and change them dynamically. For instance, we have to set the "min" value to the minimal number of supported vcpus but adjust the "step" when the user clicks in increase/decrease to make sure it is a value multiple of cores * threads. Please let me know if the default html5 specification works for you. If you think the +/- signs are extremely necessary then I will have to create a custom JS widget for this. Samuel -----Original Message----- From: kimchi-devel-bounces@ovirt.org [mailto:kimchi-devel-bounces@ovirt.org] On Behalf Of Lucio Correia Sent: quarta-feira, 13 de janeiro de 2016 15:49 To: Kimchi Devel <kimchi-devel@ovirt.org> Subject: [Kimchi-devel] [RFC] Allow user to specify max virtual cpus in template and guest Current State ------------- Currently we have the following values defined for a KVM guest created by Kimchi: <vcpu placement='static' current='4'>252</vcpu> <cpu> <topology sockets='63' cores='2' threads='2'/> </cpu> User specifies the processor topology (optional) and the number of virtual CPUs and sockets are calculated by Kimchi based on maximum supported by the hypervisor (varies with distro) this way: maximum number of virtual cpus supported = 255 (taken from hypervisor) processor topology: cores=2 , threads=2 (optionally specified by user) number of virtual cpus per socket: cores * threads = 4 (from topology) maximum number of sockets guest can have = int(255/4) = 63 maximum number of virtual cpus guest can use = 4 * 63 = 252 Proposal -------- Allow user to specify the maximum number of virtual cpus for a template or guest (when this one is offline - not running). Changes required ---------------- 1) Backend A) Add "maxvcpus" optional field to both template and guest APIs Restrictions to be implemented on this value: - must be a positive integer - must be a multiple of (cores * threads) - must be less than or equal the maximum number of virtual cpus supported by hypervisor If not specified, the default value for maxvcpus will be the equivalent to one socket (that is, core * threads). B) Change the way number of sockets is calculated: maximum number of virtual cpus supported = 255 (taken from hypervisor) topology: cores=2 , threads=2 (specified by user) maximum number of virtual cpus guest can use = 100 (specified by user) number of virtual cpus per socket: cores * threads = 4 (from topology) maximum number of sockets guest can have = int(100/4) = 25 maximum number of virtual cpus guest can use = 4 * 25 = 100 That would result in: <vcpu placement='static' current='4'>100</vcpu> <cpu> <topology sockets='25' cores='2' threads='2'/> </cpu> C) Update/Add unit tests 2) Frontend A) Edit Template, at "Processor" tab: - change the current "CPU number" field to a -[]+ input field (increase/decrease) - add a new -[]+ input field "Max CPU number" (increase/decrease) for user input of "max virtual CPUs". Restrictions from 1.A) apply here. Despite it's in a different place, we may use a "More Options" artifact similar to the one proposed by Rodrigo Trujillo at "[RFC][Kimchi] Guest Max memory setup and update", to keep the same format. B) Edit Guest, at "General" tab: - add a new -[]+ input field "Max CPUs" (increase/decrease in terms of core * threads) for user input of "max virtual CPUs". This new field is only enabled if guest is not running. Restrictions from 1.A) apply here. Let me know your thoughts. Thanks, -- Lucio Correia Software Engineer IBM LTC Brazil _______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 14-01-2016 08:59, Samuel Henrique De Oliveira Guimaraes wrote:
Hi,
I think this looks great. For the UI, the decrease/increase input we can use the input type "number":
http://www.w3schools.com/html/tryit.asp?filename=tryhtml_input_number
However we can't change the arrows to + and - signs and in IE and Edge it doesn't show any arrows at all. By default it only support numbers but if the user paste any other character it will fill the max character limit (set with the "max" attribute) with the letter "e". I can validate this on the front-end with the "pattern" attribute and for older browsers that don't support it I could put a regex on it. This table shows the current browser support of it: http://caniuse.com/#feat=input-number. I think there are some other known issues with Firefox older than 28 and ESR that are not covered within this list.
Based on the back-end specification I think we can mix some of the html5 native attributes with JavaScript to perform the form validation on the front-end. This is the JavaScript spec for this input type: http://www.w3schools.com/jsref/dom_obj_number.asp
We could get some values from the back-end and set the attributes on the front-end and change them dynamically. For instance, we have to set the "min" value to the minimal number of supported vcpus but adjust the "step" when the user clicks in increase/decrease to make sure it is a value multiple of cores * threads.
Please let me know if the default html5 specification works for you. If you think the +/- signs are extremely necessary then I will have to create a custom JS widget for this.
Samuel
Hi Samuel, thanks for the feedback. I believe html5 spec is enough. We just need to keep the same standard for this and for the other RFC from Rodrigo "[RFC][Kimchi] Guest Max memory setup and update". I will send a V2 with changes I did during backend implementation. Regards, -- Lucio Correia Software Engineer IBM LTC Brazil
participants (3)
-
Lucio Correia -
Paulo Ricardo Paz Vital -
Samuel Henrique De Oliveira Guimaraes