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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
