Re: [Xen-devel] memory hotplug for domUs

[Juergen Gross <jgross@xxxxxxxx>]

On 03/02/17 13:19, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] memory hotplug for domUs"):
>> While the syntax for "xl mem-add" (or however we would call it) could
>> be rather clear and simple:
>>
>> xl mem-add <domain> <mem-amount> [--host-node <xy>] [--guest-node <ab>]
>>
>> I don't see how this would be the case for xl mem-set. Imagine a guest
>> ballooned down and now you are setting a memory size above its current
>> maxmem value. What should be done? Should the guest first be ballooned
>> up and then a hotplug operation is to happen? Or should all the memory
>> missing be added via hotplug? Should xl mem-set with numa nodes
>> specified be rejected in case the requested size could be achieved by
>> ballooning up?
>>
>> In case of removing memory: should ballooning or hotplug or a
>> combination of both be used?
>>
>> With xl mem-add/mem-remove this would be very clear. We could even
>> support adding pre-ballooned memory (might be interesting in case a
>> guest supports only hotplugging of specific memory sizes but one
>> wants to add less host memory to the guest).
> 
> The problem I have with this approach is that from most users' point
> of view, static-max is not a very meaningful concept.  If the user has
> to `mem-add' iff the new amount is bigger than the static-max, this
> makes the whole thing very odd to use.
> 
> I do see that these numa node allocation possibilities make matters
> more complicated, but the usual case is that the user will want the
> default numa allocation strategy; and the next usual case is that they
> specified an allocation strategy at domain creation time, in the
> domain config file.  I don't think the dynamic numa special cases
> should be allowed to force us into making an interface which is
> unnatural in the usual cases.
> 
> Bottom line: I want `xl mem-set', without further options, when
> supported by the guest, to automatically do any memory hotplug that
> may be required, according to the domain's existing numa allocation
> policy (whatever that may be).
> 
> For users who want to adjust the numa allocation strategy during the
> life of the domain, I am content that there should be more complex
> mechanisms.  So I don't think we need numa options to mem-set unless
> that is the most convenient interface.

Okay. This means for me:

As user interface we are starting with "xl mem-set" which will use
memory hotplug if necessary and supported by the guest (guest indicates
support via a Xenstore entry). A "force" parameter can be used with
"xl mem-set" in case there is no support indicated in Xenstore. In the
beginning memory hotplug will be supported for pv guests only.

The memory hotplug functionality is offered by a libxl function which
can be used by e.g. libvirt and, of course, by "xl mem-set". Support
of memory hotplug by a guest can be tested by another libxl function.

In case it is needed we can add more xl commands in order to support
e.g. special numa functionality.

Should we already consider numa parameters at the libxl interface
(for now accepting "ANY" parameter only)?


Juergen

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel