On Thu, Feb 01, 2018 at 02:44:03PM +0100, Andrea Bolognani wrote: > On Thu, 2018-02-01 at 12:54 +0000, Daniel P. Berrangé wrote: > > > If an application breaks based on the USB controller being either > > > present or not present, then they shouldn't be relying on libvirt's > > > default but rather explicitly opt either in or out. > > > > It is not merely the mgmt application that may break, but the > > guest OS inside too. When we suddenly expose new hardware to a > > guest that was not previously present you can certainly trigger > > latent problems in the guest OS. It could slow boot at a key > > phase, or trigger loading of bad drivers, or any number of other > > things that can occurr when you change hardware visible to an OS. > > Note that I'm not advocating adding controllers or any other > hardware to *existing* guests - that would clearly be a guest ABI > breakage and thus Extremely Bad™. For newly-defined guests, however, > none of the above applies AFAICT. There's no practical way to distinguish an existing guest from a new guest being provisioned. With transient domains they are one & the same. Even with persistent guests the distinction is far from clear. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
