[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 2/3] maxmem: implement virDomainSetMaxMemory API of the qemu driver

On Fri, Apr 08, 2011 at 05:39:36PM -0600, Eric Blake wrote:
> On 04/07/2011 11:08 PM, Taku Izumi wrote:
> > 
> > This patch implements the code to support virDomainSetMaxMemory API,
> > and to support VIR_DOMAIN_MEM_MAXIMUM flag in qemudDomainSetMemoryFlags function.
> > As a result, we can change the maximum memory size of inactive QEMU guests.
> > 
> > +static int qemudDomainSetMaxMemory(virDomainPtr dom, unsigned long memory) {
> > +    return qemudDomainSetMemoryFlags(dom, memory,
> > +                                     VIR_DOMAIN_MEM_MAXIMUM | VIR_DOMAIN_MEM_LIVE);
> Hmm.  Given the above implementation, this will _always_ fail.  Then
> again, the failure message will be nicer (the function used to fail with
> "not implemented", now it fails with "cannot resize memory on an active
> domain"), so I guess it's okay to provide this stub.  And given the
> documentation in libvirt.c, this is accurate (that documentation
> explicitly stated that it only works on live domains).
> But the real clincher is how xen behaves.  I just tested, and my RHEL 5
> machine with xen:/// was able to change persistent max memory of an
> inactive domain, so the documentation in libvirt.c is wrong.  I then

  Hum, how did you test this ? This sounds weird to me, maybe the xen
code really improved, but basically the max memory information was used
by the hypervisor (micro) kernel to allocate things like size of page
tablesetc. for the gues and well that could not be changed dynamically,
once the guest was started say with a max_memory of 4G you would not
be able to "live" change the max_memory to 16GB and grow the guest
memory to more than 4G.

> tried an active domain, which (surprisingly) changed the max cap, then
> promptly forgot the change when the domain went inactive again proving
> that it behaved like _LIVE and not _LIVE|_CONFIG.  Qemu can't change max
> mem on a live domain (it's capped at qemu startup time) even if xen can,

  I'm still wondering about this :-)

> so if we tweak the libvirt.c wording to accommodate both xen and qemu
> behaviors (since it was already inaccurate for xen), then we can make
> this function succeed some of the time by defaulting to


Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel veillard com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]