[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Should we always dump an usb controlled in XML domains



On Tue, Apr 10, 2012 at 11:58:52AM +0800, Daniel Veillard wrote:
> 
>   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.

As with downgrading libvirt on a host, migrating a guest to an older
version of libvirt is not something we can really support, since you
run a high risk of breaking QEMU / guest ABI, due to the older libvirt
missing out some hardware device that new libvirt has added.

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

Over time we have been moving towards the scenario where we fully
describe all devices in the VM. This has been particularly important
in the area of device addressing, since applications need to know
what PCI addresses the default devices are consuming, if they want
to add new devices with fixed PCI addresses.

If we removed the default USB controller, applications would have
to hardcode knowledge of the fact that there is a USB controller
consuming address X.Y.Z. This would be a step backwards IMHO, as
we want apps to have less hardcoded knowledge of this kind

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]