On Thu, 2018-02-01 at 15:49 +0100, Peter Krempa wrote:
> 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.
I would never suggest changing controller models :)
> 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.
Okay, the one about drivers is a reasonable point.
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.
I also realized that my patch would not do what I wanted it to in
any case, because adds the USB controller and memory balloon to
guests without even inspecting the flags.
Looks like we're stuck with management applications having to deal
with this themselvels. Oh well.
--
Andrea Bolognani / Red Hat / Virtualization