On Mon, Aug 09, 2010 at 08:34:23PM +0200, Daniel Veillard wrote:
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.
Since we automagically add the devices to describe an internal policy I think we're at fault here.
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>
Grumpf ... that mean at the internal stucture level we need to add an extra field, that is detected at a completely different time in parsing too ... more complex in general, but I can understand the purity POV.
I don't see this as a real problem. It is no different from the way that we automatically add <controller> devices at the end of parsing, if we saw any <disk> or <channel> devices previously. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|