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

[Samuel Guimarães]

2016-01-11 14:29 GMT-02:00 Rodrigo Trujillo <
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>:
>
>> 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.


>
>
> - 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
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>
>
>
> _______________________________________________
> Kimchi-devel mailing listKimchi-devel at ovirt.orghttp://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/60f90a48/attachment.html>