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@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