I realize that we have that behaviour for quite some times but I
wonder about it, basically we always dump an usb controller on the
XML domain format:
<controller type='usb' index='0'/>
even if there is no USB device connected to the machine. The drawback
I see is that if we try to reuse (or migrate) that domain to an older
verlion of libvirt without that USB controller support, then we just
fail to parse the domain, even though we don't need the missing
capability.
So I wonder if the correct thing isn't to add the USB controller
only if there is an USB device associated to the domain, then failure
to migrate on an older libvirt does make sense because we require the
feature. I would assume that application using the USB support wouldn't
need to have the USB hub exposed to allow adding an USB device, and once
the USB device is added then changing the kind of USB hub to select
a different version does make sense.
In general I'm tempted to not dump in the XML things which are there
by default and would be automatically added if changed or used in some
ways. I think there is two advantages to this:
- keep the XML smaller and somehow more readable
- avoid portability problems on unsupported but unused constructs
One drawback I could perceive though is that having defaults values not
explicitely dumped in the XML could lead to change of guest behaviour if
we changed the default meaning of such default value. But we can just
document this (like for reserved PCI default slots) and do our best to
not breakdefault behaviour.
Opinion ?
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/