On Wed, Mar 04, 2015 at 03:25:31PM +0100, Peter Krempa wrote:
Adding Dan && Eric to cc
I already did that in my mail, but since the subject didn't start with "Re:" and they have de-duplication turned on, you can't see them here (thank the mailman, I guess).
On Thu, Feb 26, 2015 at 14:06:55 +0100, Martin Kletzander wrote: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>This depends on how you want to interpret the <memory> element. Currently it is stored in variable called "max_balloon" so in that case my implementation is closer to the existing meaning as the max_balloon memory is actually available in the address space of the guest until the guest decides to enable the memory balloon.
Yes, it is closer, from a developers' point of view. I was just trying to make it look nicer and probably a bit more usable from the users' POV.
As a fact, both of those approaches have to have NUMA enabled though so you can configure the size of the initial memory. If we wanted to change the way we are configuring this we might want to consider whether we ever want to enable memory hotplug for non-NUMA guests and thus have to introduce both <maxMemory> and <actualMemory> or similar.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.Since the field is internally called max_ballon, every change will probably trigger some refactors.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.This looks definitely more complex ...I'm just trying to make our (as well as mgmt app developers' and libvirt users') lives easier>... since you want to achieve this ^^
Yes, I didn't say it's an easier choice ;) But anyway, it looks like nobody expressed their opinions while I was offline for about a week, so let's just go with your approach, then (unless you've changed your mind :) ).
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. MartinPeter
Attachment:
pgpXACtHuoDKJ.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list