[Kimchi-devel] [PATCH 0/6 - V2][Memory HotPlug] Implements backend of memory device hotplug

[Rodrigo Trujillo]

Hi Aline, thank you for the review.

See my answers in below and in next emails.

Rodrigo

On 06/01/2015 09:18 AM, Aline Manera wrote:
>
>
> On 28/05/2015 10:59, Rodrigo Trujillo wrote:
>> V2
>> - Fix erros in tests and add a test to slots number
>> - Fix other minor issues with Libvirt < 1.2.14
>>
>> V1
>> This patchset implements the backend part of memory hotplug 
>> functionality,
>> including:
>> - new feature test to check if libvirt supports memory devices
>> - changes the way that memory is assigned or updated in the guest xml:
>>     * memory is now set in a basic NUMA node
>> - includes maxMemory element in the XML:
>>     * which is equal the total memory of the host
>>     * sets memory device slots. The total number of slots are equal the
>>            maxMemory minus the memory assigned (1 slot == 1 GB )
>> - creates a new VM device, the memory device:
>>     * by default, a memory device will have 1GB
>>     * user can add the memory device with machine running or offline
>> - memory devices are selected according to its position in the xml 
>> (the slot)
>>    0, 1, 2, etc
>
>> URL:
>>     - http://localhost:8010/vms/<VM>/memdevices
>>     - http://localhost:8010/vms/<VM>/memdevices/<MEM-DEV>
>
> I understand why you created the API like above, but from a user 
> perspective I just want to increase the guest memory and it should be 
> transparent to user.
>
> I'd expect the API to use the PUT /vms/<name> {memory: 2048}

I developed this feature thinking in 2 environments: VM running and VM 
stopped.
If the VM is stopped then user or UI would have to use "PUT /vms/<name> 
{memory: 2048}"
If the VM is running then user or UI would have to use "POST 
/vms/<name>/memdevides    {amount: 2}
 From the UI side, there would not need calculation, just  check if the 
VM is running, use different elements and do a different call, notice 
that if the VM is running it will only accept integer amounts of GiB.

There is no problem on use "PUT /vms/<name> {memory: 2048}" to simplify 
users life, just need to think a little bit more in the "intelligence" 
to handle the memory number passed.
The 'vm update' function can check if the vm is running or not and make 
use of the memdevice API. In order to this work correctly, I believe I 
would have to code the "memdevice remove" function as well,
or just allow to increase memory, when vm is running.

What do you think ?

>
> And then backend would do the work otherwise we will insert some 
> backend logic to frontend, as user would set the memory to 2048 and UI 
> should calculate how many memory devices should be added. What about 
> one of those requests fails? UI would need to do a callback to revert 
> the successful requests.
hum, actually what have thought is not allow user to set a number as 
memory, in the UI, if the guest is running. Instead, show the current 
memory in a disabled label, and add a second label with the number of Gb 
to add, like:

                 ---------                       ----
Memory   | 2048 |    Add (GB)   | 0 |     ( + )  ( - )
                 ---------                       ----


The UI would do only 1 more request for the memory.
But that is what I have thought, we can keep the UI as is and add the 
handling in the update function.


>>
>> Rodrigo Trujillo (6):
>>    [Memory HotPlug] Feature test to check support to memory devices
>>    [Memory HotPlug] Add maxMemory and numa configuration to guest xml
>>    [Memory HotPlug] Memory device control and model classes
>>    [Memory HotPlug] Add parameters checking  and documentation to memory
>>      device API
>>    [Memory HotPlug] Fix VM offline memory update and fix slots 
>> assignment
>>    [Memory HotPlug] Fix test and adds slot test
>>
>>   docs/API.md                         | 16 +++++++
>>   src/kimchi/API.json                 | 14 +++++-
>>   src/kimchi/control/vm/memdevices.py | 47 +++++++++++++++++++
>>   src/kimchi/i18n.py                  |  5 ++
>>   src/kimchi/mockmodel.py             |  7 +++
>>   src/kimchi/model/config.py          |  3 ++
>>   src/kimchi/model/featuretests.py    | 43 +++++++++++++++++
>>   src/kimchi/model/vmmemdevices.py    | 94 
>> +++++++++++++++++++++++++++++++++++++
>>   src/kimchi/model/vms.py             | 85 
>> ++++++++++++++++++++++++++++-----
>>   src/kimchi/vmtemplate.py            | 40 ++++++++++++----
>>   tests/test_model.py                 |  2 +-
>>   tests/test_rest.py                  |  4 +-
>>   tests/test_vmtemplate.py            |  5 +-
>>   13 files changed, 338 insertions(+), 27 deletions(-)
>>   create mode 100644 src/kimchi/control/vm/memdevices.py
>>   create mode 100644 src/kimchi/model/vmmemdevices.py
>>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>