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. > Even exposing hardware that has no guest support at all can be > problematic. The reason we had to add memballoon model=none support > originally was that users & tools were not happy with Windows > device manager showing an "unknown" device with no driver present. All guest OSs you might want to run on aarch64/virt support both USB3 and virtio-memballoon AFAIK, so this shouldn't be an issue either. > > We don't offer any guarantees when it comes to what new guests > > will look like, though, only that we won't alter existing ones. > > As long as the machine type hasn't changed, the new guests should > get exactly the same hardware as previosly deployed guests had. > When we've violated that in the past it has caused problems. We > have knowingly change this in the past when we believed there > were no significant production users (eg when aarch64 switched > to PCI instread of MMIO by default, or we changed controller > setup on q35). In general we must not do these kind of things > on stuff that is expected to be in active use. I think that's too strict a policy, one that we have very little chance of actually being able to enforce. We certainly haven't in the past, eg. any time we started picking a better controller or device by default, or tweaked our PCI device placement algorithm, knowing that existing guests had the model and address stored in the XML and thus would not be affected. If a management application or a user is completely reliant on guests presenting a very specific set of devices or address allocation, then they should be passing all those information to libvirt in the first place. > So I stil consider this change to be something we should not > do. It is easy to fix Nova to setup USB if it desires it, so > there's no blocking item that requires us to do this in libvirt. It's not really blocking anything, because of course there are ways around it and, as mentioned, requesting an USB controller explicitly is always better than assuming libvirt will provide you with one. Still, it's a pointless difference between the mostly identical x86_64/q35 and aarch64/virt, so it would be nice to get rid of it. But I guess I'm to blame for not realizing earlier :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
