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

Re: [libvirt] SetMaxMemory vs. SetMemory



On Fri, May 22, 2009 at 02:27:23PM +0200, Matthias Bolte wrote:
> 2009/5/22 Daniel P. Berrange <berrange redhat com>:
> > Actually QEMU, KVM, Xen PV, Xen FV all  follow the same model, providing
> > you have the balloon driver available in the guest. 'maxmem', confusingly
> > calling <memory> in the XML sets the maximum possible memory  for the
> > guest, as exposed in e820 maps. When the guest runs this maximum can be
> > reduced setting 'memory', confusingly called <currentMemory> in the XML,
> > to a lower value. The hosts talks to the balloon driver in the guest and
> > asks it to release memory. This isn't a guarenteed lower limit, since it
> > relies on guest cooperation, but at least the guest is aware of what
> > the host it telling it todo.
> >
> > Depending on bugs in the guest ballloon driver, the 'free' command may or
> > may not, update the 'total memory' setting in the guest.
> >
> > What Matthias is talking about wrt  VMWare ESX is about how the hypervisor
> > satisfies the memory allocation for the guest, eg how much real RAM ist
> > guarantees, with the rest of guest RAM susceptible to swapping. This is
> > more of a tuning parameter, and does not map onto the libvirt memory/maxmem
> > settings.
> 
> Well, ESX has support for ballooning, too. If the balloon driver is
> installed inside the guest, then ESX does the same as you described
> for QEMU etc. If you set the memory value (the limit in ESX terms)
> below the max-memory value, ESX lets the balloon driver allocate
> memory in the guest to "steal" it from the guest. But ESX can do this
> even without the balloon driver by swapping, as you described in the
> third paragraph. So IMHO this maps somewhat onto the libvirt
> memory/max-memory semantics, if the balloon driver is installed. See
> also http://www.vmware.com/pdf/esx3_memory.pdf page 3-4, "Memory
> Balloon Driver" and "Swapping".

Ahh, soo setting a memory limit will adjust both the host side allocation
policy and inform the balloon driver. With that scheme, then yes, it does
make sense to use 'max mem' for the initial VM memory allocation, and
then use the 'memory' setting to control the balloon driver in ESX.


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


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