Re: [libvirt] [PATCH] qemu: Add USB and memory balloon by default for aarch64/virt guests
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 :|