[Kimchi-devel] [RFC][Kimchi] Guest Max memory setup and update

[Rodrigo Trujillo]

On 01/11/2016 02:46 PM, Samuel Guimarães wrote:
>
>
> 2016-01-11 14:29 GMT-02:00 Rodrigo Trujillo 
> <rodrigo.trujillo at linux.vnet.ibm.com 
> <mailto:rodrigo.trujillo at linux.vnet.ibm.com>>:
>
>
>     On 01/11/2016 12:56 PM, Samuel Guimarães wrote:
>>     Hi team,
>>
>>     I have some questions. I've wrote them below the requirements for
>>     the front-end.
>>
>>     Samuel
>>
>>     2016-01-08 16:18 GMT-02:00 Rodrigo Trujillo
>>     <rodrigo.trujillo at linux.vnet.ibm.com
>>     <mailto:rodrigo.trujillo at linux.vnet.ibm.com>>:
>>
>>         Hi all,
>>
>>         The guest xml tag <max_memory> is necessary to allow memory
>>         hotplug. Currently, max_memory is the lesser value among
>>         "guest memory X4",  "Host Memory" or "1TB". It is also not
>>         possible to user, to set it.
>>
>>         Proposal: Modify backend and frontend in order to allow users
>>         to increase/decrease max_memory value. In other words, user
>>         will be allowed to set the amount of memory that will be
>>         possible to hotplug.
>>
>>         BACKEND   (a previous patch was already sent to mailing list,
>>         must sent new version)
>>         - Remove current settings when guest is created. Set
>>         max_memory equal guest memory.;
>>         - Does not allow change max_memory when guest is running;
>>         - When hotplug, continue with slots of 1GB, but restrict 32
>>         slots in PowerPC;
>>         - Update/Add tests;
>>         - Change JSON memory field to:   memory: { current: XXX,
>>         maxmemory: YYYY };
>>
>>
>>         FRONTEND
>>
>>         - In guest edit window,  modify memory input field. Change it
>>         to a increase/decrease ( +/- ) input box;
>>
>>
>>     IE9, 10, 11 and Edge doesn't fully support input "number" yet.
>>     They display as a regular text field with a "x" to clear the
>>     field and accept only numbers but they don't show the double
>>     arrows (that we can't change to + and - even in Chrome). If we
>>     all agree I'm ok to change the input type from text to number
>>     regardless of these known issues.
>     I am ok with this.
>
>>         - Create a hidden area which will hold max memory input box
>>         (increase/decrease);
>>
>>         - Increments will be of 1GB;
>>
>>
>>     Is this increment rule only for the Max Memory input or also for
>>     the current memory? What happens If the user start editing a VM
>>     that was created outside Kimchi and has set the maximum memory to
>>     something like 768MB? Should the input fill the memory to 1024MB
>>     and then on the next click in the arrow go to 2048MB or add
>>     1024MB on top of the current memory?
>     Both memories.
>     For machines created outside Kimchi, or even in Kimchi command
>     line... always show the saved value... then when user increase or
>     decrease, round it to next GB value.
>
>
> Ok! This can be done with the "step" attribute in the input number 
> (which is supported by IE). I think we should get the step value by 
> the back-end and change the attribute by JS in case we have a specific 
> machine that supports more than 1GB.
I don't believe it is necessary to send the step value to front end. 
Actually, increase/decrease by one GB is only required in memory 
hotplug... backend is going to return an error, if wrong value is passed.

Question, even with the number arrow input, is it possible to user to 
fill a custom value ?


>
>
>>         - Create a "More Options" link besides Memory , that is going
>>         to show/hide  max memory area;
>>         - If guest is online:
>>             * max memory field will be disabled;
>>             * memory will be enabled, allowing hotplug;
>>         - When guest is offline, it is ok to change max memory,
>>         enable it;
>>
>>
>>         API CHANGES:
>>
>>         JSON must be changed in requests and responses:
>>             - When updating guest (PUT), memory field will become:
>>                     memory: { current: <memory new value>, maxmemory:
>>         <maxmemory new value> }
>>             - response (GET):
>>                     memory: { current: <memory new value>, maxmemory:
>>         <maxmemory new value> }
>>
>>         It is not necessary to include maxmemory if was not changed.
>>
>>         Thoughts ?
>>
>>         Rodrigo Trujillo
>>
>>         _______________________________________________
>>         Kimchi-devel mailing list
>>         Kimchi-devel at ovirt.org <mailto:Kimchi-devel at ovirt.org>
>>         http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>>
>>
>>
>>     _______________________________________________
>>     Kimchi-devel mailing list
>>     Kimchi-devel at ovirt.org <mailto:Kimchi-devel at ovirt.org>
>>     http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
>
>     _______________________________________________
>     Kimchi-devel mailing list
>     Kimchi-devel at ovirt.org <mailto:Kimchi-devel at ovirt.org>
>     http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
>
>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160111/c6e134f7/attachment.html>