On Mon, Jan 29, 2018 at 01:04:33PM +0100, Andrea Bolognani wrote: > On Thu, 2018-01-25 at 16:58 +0000, Daniel P. Berrangé wrote: > > On Thu, Jan 25, 2018 at 05:45:51PM +0100, Andrea Bolognani wrote: > > > Basically all existing guest types, regardless of the architectur, > > > get both a USB controller and a virtio memory balloon by default. > > > > > > s390 guests are an exception, for the very good reason that they > > > don't support USB at all; the other exception is aarch64/virt > > > guests, but in the latter case isn't a compelling reason for them > > > to deviate from the widely adopted convention, especially since: > > > > > > * x86/q35 guests, which aarch64/virt guests are for the most > > > part identical to, add these devices by default; > > > * it's trivial to opt out of both default devices by setting > > > model='none'; > > > > Except that this requires code changes to downstream applications to > > actually do this now, otherwise guests that they were expecting to > > not have USB for, now suddenly get it. > > 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. 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. > > > So add it by default for newly-defined guests. Existing guests > > > will, of course, be left unchanged. > > > > That is still harmful, because an existing mgmt application release that > > runs on new libvirt has its guest configs suddenly changed, especially > > if using transient guests. > > 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. 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. 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
