On Thu, Jan 14, 2021 at 04:25:21PM +0100, Christian Borntraeger wrote: > On 14.01.21 15:15, Daniel P. Berrangé wrote: > > On Thu, Jan 14, 2021 at 03:09:01PM +0100, Christian Borntraeger wrote: > >> > >> > >> On 14.01.21 15:04, Cornelia Huck wrote: > >> > >> What about a libvirt change that removes the unpack from the host-model as > >> soon as only-migrateable is used. When that is in place, QEMU can reject > >> the combination of only-migrateable + unpack. > > > > I think libvirt needs to just unconditionally remove unpack from host-model > > regardless, and require an explicit opt in. We can do that in libvirt > > without compat problems, because we track the expansion of "host-model" > > for existing running guests. > > This is true for running guests, but not for shutdown and restart. > > I would really like to avoid bad (and hard to debug) surprises that a guest boots > fine with libvirt version x and then fail with x+1. So at the beginning > I am fine with libvirt removing "unpack" from the default host model expansion > if the --only-migrateable parameter is used. Now I look into libvirt and I > cannot actually find code that uses this parameter. Are there some patches > posted somewhere? Sorryy, I should have been clearer that we don't currently use --only-migrateable. I've been talking from the pov of the effects if we were to introduce it into libvirt. The way it would work would be for 'virsh start FOO' to start the guest unconditionally, while 'virsh start --migratable FOO' would start the same guest config but fail if it used a non-migratable feature. We need the guest ABI to be the same in both cases. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
