[libvirt] [PATCH] allow memballoon type of none to desactivate it

[Daniel Veillard]

On Mon, Aug 09, 2010 at 06:53:34PM +0100, Daniel P. Berrange wrote:
> On Mon, Aug 09, 2010 at 06:38:27PM +0200, Daniel Veillard wrote:
> >   The balloon device is automatically added to qemu guests if supported,
> > but it may be useful to desactivate it. The simplest to not change the
> > existing behaviour is to allow
> >   <memballoon type="none"/>
> > as an extra option to desactivate it (it is automatically added if the
> > memballoon construct is missing for the domain).
> > The following simple patch just adds the extra option and does not
> > change the default behaviour but avoid creating a balloon device if
> > type="none" is used.
>  
> I really don't like the idea of 'type=none' devices in general.
> I don't	think we should	have an	element	insides <devices> that
> doesn't	actually represent a device.
> 
> If we want to disable the balloon, then	I think	we should aim
> for an element or attribute elsewhere to toggle it.
> 
> eg, perhaps the	earlier <memory> element can indicate whether it
> supports ballooning. eg
> 
>   <memory ballonable='yes|no'>2423423432</memory>
> 
> Thus if	ballooning is not enabled, the <memballoon> device would
> never need to appear within <devices>

 Okay being stuck and having though about the issue for a couple of days
I think <memballoon type="none"/> is the most pragmatic way to avoid
forcing the memballoon device on QEmu/KVM users at this point.
 The issue in general of memory configuration is somehow a mess as
you pointed out, there is 4 tunables or constructs appaering to control
them, but getting to a cleaner way to manage this may take some time.
 I'm taking the responsability of adding that extra enum in the list and
the single line change in the qemu code (the other change is just a
comment), and whatever solution we may end up with I think it will be
trivial to detect the enum value and switch it on the fly. From a device
management perspective since there can be only 1 <memballoon> device
per guest I think handling this issue should be trivial there too.
So I commited that vary small patch and will take the burden of making
the conversion to whatever construct we may end up picking on the long
term for this setting.

Daniel

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