Re: [libvirt] [RFC PATCH 02/12] conf: Add support for parsing and formatting max memory and slot count

On Thu, Feb 05, 2015 at 20:54:11 -0700, Eric Blake wrote: > On 01/30/2015 06:20 AM, Peter Krempa wrote: > > Add a XML element that will allow to specify maximum supportable memory > > s/a XML/an XML/ > > > and the count of memory slots to use with memory hotplug. > > Might be nice to demonstrate that XML here in the commit message, not > just in formatdomain.html. > > > > > To avoid possible confusion and misuse of the new element this patch > > also explicitly forbids the use of the maxMemory setting in individual > > drivers's post parse callbacks. This limitation will be lifted when the > > s/drivers's/drivers'/ > > > support will be implemented. > > --- > > docs/formatdomain.html.in | 19 +++++++++++ > > docs/schemas/domaincommon.rng | 8 +++++ > > src/bhyve/bhyve_domain.c | 4 +++ > > src/conf/domain_conf.c | 64 ++++++++++++++++++++++++++++++++++++ > > src/conf/domain_conf.h | 7 ++++ > > src/libvirt_private.syms | 1 + > > src/libxl/libxl_domain.c | 5 +++ > > src/lxc/lxc_domain.c | 4 +++ > > src/openvz/openvz_driver.c | 11 +++++-- > > src/parallels/parallels_driver.c | 6 +++- > > src/phyp/phyp_driver.c | 6 +++- > > src/qemu/qemu_domain.c | 4 +++ > > src/uml/uml_driver.c | 6 +++- > > src/vbox/vbox_common.c | 6 +++- > > src/vmware/vmware_driver.c | 6 +++- > > src/vmx/vmx.c | 6 +++- > > src/xen/xen_driver.c | 4 +++ > > src/xenapi/xenapi_driver.c | 6 +++- > > tests/domainschemadata/maxMemory.xml | 19 +++++++++++ > > 19 files changed, 183 insertions(+), 9 deletions(-) > > create mode 100644 tests/domainschemadata/maxMemory.xml > > > > diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in > > index f8d5f89..12f7ede 100644 > > --- a/docs/formatdomain.html.in > > +++ b/docs/formatdomain.html.in > > @@ -664,6 +664,7 @@ > > <pre> > > &lt;domain&gt; > > ... > > + &lt;maxMemory slots='123' unit='KiB'&gt;1524288&lt;/maxMemory&gt; > > 123 is unusual; the example would look more realistic with a power of 2. > > > &lt;memory unit='KiB'&gt;524288&lt;/memory&gt; > > &lt;currentMemory unit='KiB'&gt;524288&lt;/currentMemory&gt; > > Hmm. Historically, <memory> was the maximum memory, then ballooning was > introduced and <currentMemory> was added to show the live difference > between the ballooned current value and the boot-up maximum. > > But with the idea of hot-plug, I see where you are coming from - the > balloon can only inflate or deflate up to the amount of memory currently > plugged in, so <maxMemory> is the startup maximum, <memory> becomes the yes, maxMemory is basically size of guest's address space > amount plugged in, and <currentMemory> reflects the balloon value (that Now <memory> is a thing we need to clarify, there are two options: 1) <memory> will still determine the amount of startup memory thus will not include any memory added via "memory modules" or hotplug. Pros: - no change to semantics - no need to take care of changing the value when adding devices - the value will not change with hotplug or other operations Cons: - I'll have to add a way to express the "current maximum memory" - the memory amount with the ballon deflated 2) <memory> will become total of initial and added memory This will change semantics and require us to recalculate the totals every time. Pros: - you are able to see the total memory at any time - no need to introduce any new parameter for balloon setup - recalculating the total would actually fix the bug when you specify /domain/memory less than the sum of /domain/cpu/numa/cell/@memory : error: internal error: process exited while connecting to monitor: 2015-02-06T17:00:55.971851Z qemu-system-x86_64: total memory for NUMA nodes (0x40000000) should equal RAM size (0x100000) Cons: - we would need to calculate the total memory always (thus overwrite it's value by a sum of the NUMA node memory and memory devices memory - aplications would need to actually check for the change of the max memory

> is, current <= memory <= max). So I guess this makes sense; it may be > more interesting figuring out how to expose it all through virsh. > > > ... > > @@ -697,6 +698,24 @@ > > <span class='since'><code>unit</code> since 0.9.11</span>, > > <span class='since'><code>dumpCore</code> since 0.10.2 > > (QEMU only)</span></dd> > > + <dt><code>maxMemory</code></dt> > > + <dd>The run time maximum memory allocation of the guest. The initial > > + memory specified by <code>&lt;memory&gt;</code> can be increased by > > + hot-plugging of memory to the limit specified by this element. > > + > > + The <code>unit</code> attribute behaves the same as for > > + <code>memory</code>. > > + > > + The <code>slots</code> attribute specifies the number of slots > > + available for adding memory to the guest. The bounds are hypervisor > > + specific. > > + > > + Note that due to alignment of the memory chunks added via memory > > + hotplug the full size allocation specified by this element may be > > + impossible to achieve. > > Is a hypervisor free to reject requests that aren't aligned properly? > With <memory>, we had the odd situation that we allowed the hypervisor > to round requests up, so that live numbers were different than the > original startup numbers; it might be easier to not repeat that. > > > > + <optional> > > + <element name="maxMemory"> > > + <ref name="scaledInteger"/> > > + <attribute name="slots"> > > + <ref name="unsignedInt"/> > > + </attribute> > > This says the slots attribute mandatory; is there ever a reason to allow > it to be optional (defaulting to one slot, an all-or-none hotplug)? qemu enforces it that way, so I went for strictly all-or-none with the possibility to relax it once a different hypervisor will not enforce it