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

[Peter Krempa]

On Thu, Feb 01, 2018 at 15:24:32 +0100, Andrea Bolognani wrote:
> On Thu, 2018-02-01 at 13:52 +0000, Daniel P. Berrangé wrote:
> > > 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.
> > 
> > There's no practical way to distinguish an existing guest from a
> > new guest being provisioned. With transient domains they are one &
> > the same. Even with persistent guests the distinction is far from
> > clear.
> 
> We have VIR_DOMAIN_DEF_PARSE_ABI_UPDATE, which is only passed in
> when the guest is new - or the user has updated the XML themselves,
> in which case all bets are off when it comes to guest ABI stability
> anyway.

Even with this flag we can't just change anything. Maybe I named that
flag wrong, but it was really meant for stuff that would break a running
(or saved guest) if changed, but does not really change the hardware
itself too much. One example is the update of memory sizes in certain
situations.

This does not give us free card of changing hardware models or adding
new stuff even in cases where we know that the machine will be booted
again simply for the fact that the OS may misbehave.

> There are cases, when importing an existing OS image as opposed to
> installing from scratch, where scenarios like the ones you described
> might show up, but again I don't think it's realistic to expect all
> guests to have the same exact hardware regardless of libvirt version
> as long as they share machine type. I don't think we want to paint
> ourselves in that corner.

It may be not realistic in some cases but we seem to try really hard to
achieve this. Examples exactly described in this thread. Memory baloon
or USB was enabled by default in qemu a very long time ago and to this
day we honor this on the x86 platform.

> Plus, even if we did everything right in libvirt, guests defined at
> different times would end up having different ABI if QEMU has been
> upgraded in the meantime and thus uses a new default machine type.

The notion of the machine type is important for migration. In such case
the machine needs to be exactly the same since you can't detect any
difference.

Even when you are guaranteed to know that the VM will be booted freshly
the models of hardware in use should not change since your OS may
contain only drivers used at the installation time and your VM would not
work again. During the boot-up procedure you can change some things,
e.g. PCI addresses and stuff which is generally allowed to change.

As Daniel said ... it's impossible to know for libvirt whether a given
VM is being installed or it's old and the VIR_DOMAIN_DEF_PARSE_ABI_UPDATE
flag is definitely not the one we can base such decisions on.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180201/89dd05c0/attachment-0001.sig>