Re: [libvirt] [RFC] Memory hotplug naming [Was: [PATCHv2 3/7] conf: Replace access to def->mem.max_balloon with accessor functions]

On Wed, Feb 25, 2015 at 11:22:02AM +0100, Peter Krempa wrote: >As there are two possible approaches to define a domain's memory size - >one used with legacy, non-NUMA VMs configured in the <memory> element >and per-node based approach on NUMA machines - the user needs to make >sure that both are specified correctly in the NUMA case. > >To avoid this burden on the user I'd like to replace the NUMA case with >automatic totaling of the memory size. To achieve this I need to replace >direct access to the virDomainMemtune's 'max_balloon' field with >two separate getters depending on the desired size. > >The two sizes are needed as: >1) Startup memory size doesn't include memory modules in some >hypervisors. >2) After startup these count as the usable memory size. > >Note that the comments for the functions are future aware and document >state that will be present after a few later patches. >--- > >Notes: > Version 2: > - renamed virDomainDefGetMemoryCurrent to virDomainDefGetMemoryActual > - changed to the initial memory accessor when starting VMs in LXC, phyp and libxl > When looking at these accessors' names, I'm thinking how not to screw ourselves by naming decisions when memory hot-plug will come. If we have maxMemory, memory and currentMemory, and then have APIs where setting maximum memory actually changes "memory" and so on, we have to go through the whole documentation and everything that mentions memory just to fix the naming and we still won't be able to change API functions and flags. We will be stuck with this for fair amount of time, I guess. So I'm thinking about an approach that I haven't thought through completely, but I want to have other opinions as well. What if we used our <memory/> that we have now and started treating it as the complete maximum after all slots are filled? So instead of: <maxMemory>2048</maxMemory> <memory>1024</memory> <currentMemory>512</currentMemory> we'd have something like: <memory>2048</memory> <actualMemory>1024</actualMemory> <currentMemory>512</currentMemory>

where the main difference is the fact that memory will still be maximum memory, so we don't have to rename half of the enums, funcs and vars in the code. <actualMemory/> would be optional (the name doesn't actually matter at all) and if not specified it would just work like until now.

Yet another approach comes to mind and that is that we'll still have only <memory/> and <currentMemory/>, <memory/> gains "dimmSlots" attribute and the number of slots that are filled (and with what memory modules) will be decided upon the existence of memory devices (that is <memory/> under the <devices/> attribute). Default behaviour is still kept until "dimmSlots" (or "slots" or whatever) is not used and then the memory has to be defined by memory devices.

I'm just trying to make our (as well as mgmt app developers' and libvirt users') lives easier>

Thanks in advance for any feedback, if you think that the current idea is OK and this mail is just about donkey balls, let me know as well. Martin