[libvirt] [RFC] Memory hotplug for qemu guests and the relevant XML parts

[Martin Kletzander]

On Thu, Jul 24, 2014 at 04:30:43PM +0200, Peter Krempa wrote:
>On 07/24/14 16:21, Daniel P. Berrange wrote:
>> On Thu, Jul 24, 2014 at 02:20:22PM +0200, Peter Krempa wrote:
>
>...
>
>>>
>>> For targetting the RAM module the target element could have the
>>> following format:
>>>
>>> <target model="dimm" node='2' address='0xdeadbeef'/>
>>>
>>> "node" determines the guest numa node to connect the memory "module" to.
>>> The attribute is optional for non-numa guests or node 0 is assumed.
>>
>> If I'm thinking about this from a physical hardware POV, it doesn't
>> make a whole lot of sense for the NUMA node to be configurable at
>> the time you plug in the DIMM. The NUMA affinity is a property of
>> how the slot is wired into the memory controller. Plugging the DIMM
>> cannot change that.
>
>While this is true for physical hardware, the emulated one apparently
>supports changing a slot's position in the numa topology. Additionally
>this allows to use a non-uniform mapping of memory modules to numa nodes.
>
>Are you suggesting that we should bind certain slots to certain numa
>nodes in advance thus try to emulate the limitations of the physical
>hardware?
>
>>
>> So from that POV, I'd say that when we initially configure the
>> NUMA / huge page information for a guest at boot time, we should
>> be doing that wrt to the 'maxMemory' size, instead of the current
>> 'memory' size. ie the actual NUMA topology is all setup upfront
>> even though the DIMMS are not present for some of this topology.
>>
>>> "address" determines the address in the guest's memory space where the
>>> memory will be mapped. This is optional and not recommended being set by
>>> the user (except for special cases).
>>>
>>> For expansion the model="pflash" device may be added.
>>>
>>> For migration the target VM needs to be started with the hotplugged
>>> modules already specified on the command line, which is in line how we
>>> treat devices currently.
>>>
>>> My suggestion above contrasts with the approach Michal and Martin took
>>> when adding the numa and hugepage backing capabilities as they describe
>>> a node while this describes the memory device beneath it. I think those
>>> two approaches can co-exist whilst being mutually-exclusive. Simply when
>>> using memory hotplug, the memory will need to be specified using the
>>> memory modules. Non-hotplug guests could use the approach defined
>>> originally.
>>
>> I don't think it is viable to have two different approaches for configuring
>> NUMA / huge page information. Apps should not have to change the way they
>> configure NUMA/hugepages when they decide they want to take advantage of
>> DIMM hotplug.
>
>Well, the two approaches are orthogonal in the information they store.
>The existing approach stores the memory topology from the point of view
>of the numa node whereas the <device> based approach from the point of
>the memory module.
>
>The difference is that the existing approach currently wouldn't allow
>splitting a numa node into more memory devices to allow
>plugging/unplugging them.
>

Well, changing '<memnode cellid="1"/>' to '<memnode cellids="0-1"/>'
wouldn't require that much of a work, I guess.

I still haven't added the APIs to support changing memnode settings,
so that is open too.

Just my $0.02,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140724/f6b7a521/attachment-0001.sig>