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...
Description: Digital signature