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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list