On Thu, Mar 10, 2016 at 03:46:42PM +0100, Christophe Fergeau wrote:
Hey,
On Thu, Mar 10, 2016 at 03:20:59PM +0100, Martin Kletzander wrote:
> So this is an old, tiny series that was posted some time ago; actually
> a lot of time ago. I complained because of two things. First one
> being that there are no tests, so this series has them in. The second
> one was that this could break migration from old code since the
> parameter was not used before. So I coded up a migration flag,
> handled all the special cases and then started testing it. And while
> testing it, I've found out that QEMU doesn't care at all about this
> parameter being there and there is no point in keeping it
> super-stable, especially when it can be changed on the fly. So I
> removed all that code and ended up with tiny series very similar to
> previous attempts by various people.
I think the main problem was that if you upgrade from a QEMU which did
not care to a QEMU with the option and a libvirt which supports it,
suddenly your VMs are going to go from supporting multiple heads (4) to
only supporting one as older libvirt always add a 'heads=1' to the XML.
I'm not sure how to handle this, but I was under the impression that
this can be changed on the fly. If libvirt doesn't support that, then
we should enable it. But anyway not adding max_outputs= to commandline
when migrating from older libvirt could break something the other way
around as well.
/me quickly searches reflog for that migration code...
Christophe