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;

- Create a hidden area which will hold max memory input box (increase/decrease);

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(a)linux.vnet.ibm.com&gt;: > 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.

- 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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel > _______________________________________________ Kimchi-devel mailing listKimchi-devel@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/kimchi-devel _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel

On 01/11/2016 02:46 PM, Samuel Guimarães wrote: 2016-01-11 14:29 GMT-02:00 Rodrigo Trujillo < rodrigo.trujillo(a)linux.vnet.ibm.com&gt;: > > 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@linux.vnet.ibm.com&gt;rodrigo.trujillo(a)linux.vnet.ibm.com&gt; > : > >> 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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >> > > > > _______________________________________________ > Kimchi-devel mailing listKimchi-devel@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/kimchi-devel > > > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel > > _______________________________________________ Kimchi-devel mailing listKimchi-devel@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/kimchi-devel _______________________________________________ Kimchi-devel mailing list Kimchi-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel

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; - Create a hidden area which will hold max memory input box (increase/decrease); - Increments will be of 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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel