[libvirt] [PATCH] qemu: Add USB and memory balloon by default for aarch64/virt guests

[Andrea Bolognani]

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.

That said, I expect breakages caused by adding a controller to be
way less likely than those caused by removing one.

> >   * higher level applications such as Nova expect at least the
> >     USB controller to be present.
> 
> This doesn't really help nova in practice, because it needs to operate
> correctly with pre-existing libbvirt releases, and even on x86 it should
> not be relying on the default USB1 controller, but rather adding a USB2
> or USB3 controller.

Right. Nova should still be fixed to explicitly opt in to the USB
controller regardless of libvirt's defaults, as per the above.

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

So again, any application relying on the presence or lack of a
specific controller or device should explicitly declare so.

> > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1538637
> 
> I consider that bug wontfix.  It is just exchanging one set of problems
> for a different set of problems.

As mentioned above, any application that breaks because of a couple
of added (not removed) controllers or devices to newly-defined
guests will probably break in fairly interesting ways more often
than not.

And I believe there is value in keeping x86_64/q35 and aarch64/virt
guests closely aligned, so I still think we want to merge this or
an equivalent change.

-- 
Andrea Bolognani / Red Hat / Virtualization