[pve-devel] [PATCH] memory hotplug patch v6

[Alexandre DERUMIER]

Thanks for your suggestion,

I think it could work, but currently unplug is not implemented in qemu,
I would like to test it to see if it's working fine. (I'll try to patch qemu with last unplug patches from qemu mailing)

With this we can keep a simple memory form field (but we need to fix minimum increment with 128M instead 32M)

qm set vmid -memory x   (then compute needed dimm hotplug|unplug)

and also it's possible for advanced users to specify topology manually
qm set vmid -dimmX size,numa=node


----- Mail original -----
De: "Daniel Hunsaker" <danhunsaker at gmail.com>
À: "Gilberto Nunes" <gilberto.nunes32 at gmail.com>, "aderumier" <aderumier at odiso.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Mardi 20 Janvier 2015 20:40:30
Objet: Re: [pve-devel] [PATCH] memory hotplug patch v6



It's a bit more work internally, but changing the RAM size seems like a task that could be handled without thinking about the add/remove process. Present the user with a button/dialog to resize RAM, then hotplug and/or unplug to arrive at the target. If they provide a larger value than what's currently plugged in, hotplug the appropriate size and number of DIMMs. If it's smaller, and the size difference matches one of the currently inserted DIMMs, unplug it; otherwise find a DIMM that's larger than the size difference, plug a new module that will provide the difference between that larger DIMM and the reduced target, then unplug the larger one. If all the existing DIMMs are smaller than the size difference, you can follow a similar logic path by treating groups of two or more DIMMs as the unplug target mentioned above - if a given DIMM group matches the size difference, unplug that group; if not, find the smallest group of DIMMs you can unplug to reach the target, plug a new DIMM that will provide the amount of RAM you don't want to remove, and then unplug the group. 

Some scenarios to illustrate what I'm suggesting, since even I understand what I mean better that way than what I just said above. Each scenario builds from the previous one; the first starts with a current RAM size of 512M, using a DIMM configuration of 1 x 512M modules. 

Scenario 1: 
Target RAM - 1024M 
Action - plug 1 x 512M 
Result - 1024M (2 x 512M) 

Scenario 2: 
Target RAM - 512M 
Action - unplug 1 x 512M 
Result - 512M (1 x 512M) 

Scenario 3: 
Target RAM - 256M 
Action - plug 1 x 256M; unplug 1 x 512M 
Result - 256M (1 x 256M) 

After some more mucking about, adding memory at 256M increments, the user arrives at a configuration of 1024M (4 x 256M) for the following scenarios. 

Scenario 4: 
Target RAM - 512M 
Action - unplug 2 x 256M 
Result - 512M (2 x 256M) 

Scenario 5: 
Target RAM - 128M 
Action - plug 1 x 128M; unplug 2x256M 
Result - 128M (1 x 128M) 

A bit contrived, but illustrates the process I'm proposing. I strongly suspect that's what the other virtualization platforms are doing internally as well. It certainly simplifies the process for users who don't feel comfortable managing NUMA and similar settings directly, though it does increase the complexity of our code, and I'm certain I've simplified things here immensely. 

Just another option to consider. Either way, I like the idea of a simple process for admins in a hurry, and an advanced interface for those who are comfortable with NUMA and want complete control over their memory map. 
On Tue, Jan 20, 2015, 10:21 Gilberto Nunes < gilberto.nunes32 at gmail.com > wrote: 



BTW, how can I test this Alexandre?? 

2015-01-20 15:19 GMT-02:00 Gilberto Nunes < gilberto.nunes32 at gmail.com > : 


BQ_BEGIN

+1 

I am the one that want to see this feature in production environment.... 
It will be a plus... 



2015-01-20 15:13 GMT-02:00 Alexandre DERUMIER < aderumier at odiso.com > : 


BQ_BEGIN
>>I wonder if memory unplug is a good idea? I assume that will be the fastest way 
>>to crash most OS? 
I personnaly need this feature. (I have customers which want to add/remove memory, because we bill on that). 

For linux, it should work without any problem, if you have memory use for buffer. 
(Of course if your process need memory, you'll get OOM for sure) 



----- Mail original ----- 
De: "dietmar" < dietmar at proxmox.com > 
À: "aderumier" < aderumier at odiso.com > 
Cc: "pve-devel" < pve-devel at pve.proxmox.com > 
Envoyé: Mardi 20 Janvier 2015 18:09:13 
Objet: Re: [pve-devel] [PATCH] memory hotplug patch v6 

> what we can do 
> ------------- 
> 
> I think we can add a button "add-> memory hotplug", with a field with memory 
> value wanted. 
> We display the total memory in current hardware grid memory field. (memory + 
> total of dimms memories). 
> 
> For unplug, create a button "delete->memory unplug", 
> and in the form, display a combobox with list of current memory modules 

I wonder if memory unplug is a good idea? I assume that will be the fastest way 
to crash most OS? 
_______________________________________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel 






-- 
-- 
"A única forma de chegar ao impossível, é acreditar que é possível." 
Lewis Carroll - Alice no País das Maravilhas 

" “ The only way to achieve the impossible is to believe it is possible .” 
Lewis Carroll - Alice in Wonderland 

Gilberto Ferreira 
(47) 9676-7530 


BQ_END




-- 
-- 
"A única forma de chegar ao impossível, é acreditar que é possível." 
Lewis Carroll - Alice no País das Maravilhas 

" “ The only way to achieve the impossible is to believe it is possible .” 
Lewis Carroll - Alice in Wonderland 

Gilberto Ferreira 
(47) 9676-7530 

______________________________ _________________ 
pve-devel mailing list 
pve-devel at pve.proxmox.com 
http://pve.proxmox.com/cgi- bin/mailman/listinfo/pve-devel 

BQ_END