Adding Dan && Eric to cc 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. 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 ^^ > > 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 Peter
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list