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