[libvirt] [RFC PATCH 02/12] conf: Add support for parsing and formatting max memory and slot count
Daniel P. Berrange
berrange at redhat.com
Mon Feb 9 10:16:37 UTC 2015
On Fri, Feb 06, 2015 at 06:07:35PM +0100, Peter Krempa wrote:
> 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>
> > > <domain>
> > > ...
> > > + <maxMemory slots='123' unit='KiB'>1524288</maxMemory>
> >
> > 123 is unusual; the example would look more realistic with a power of 2.
> >
> > > <memory unit='KiB'>524288</memory>
> > > <currentMemory unit='KiB'>524288</currentMemory>
> >
> > 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
I think we should pick '2' - <memory> should always reflect the
amount of RAM currently plugged into the guest - ie sum of all DIMMS'
capacities.
If apps choose to use <maxMemory> and hotplug dimms, they'll easily
know to re-read <memory> periodically. Likewise the virDomainGetInfo
and virDomainGetMaxMemory API will need to be updated too. Damn our
API naming is annoying in this respect
> > 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><memory></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
While QEMU enforces that you always provide slots, is there any value
in just defaulting in the driver. eg if ommitted in the XML, the number
of slots just gets filled in by the driver with a sensible value for
that driver. eg we could default to adding 16 slots. Guess it isn't a
big deal since apps already have to add a new <maxMemory> element.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
More information about the libvir-list
mailing list