On Thu, 12 May 2016 15:27:04 +0200 Peter Krempa <pkrempa@redhat.com> wrote:
On Thu, May 12, 2016 at 15:20:51 +0200, Igor Mammedov wrote:
On Thu, 12 May 2016 13:04:23 +0200 Peter Krempa <pkrempa@redhat.com> wrote:
On Thu, May 12, 2016 at 07:52:23 -0300, Eduardo Habkost wrote:
I don't think we should do that, unless users already had time to update their scripts and libvirt had time to implement code supporting the new method.
I believe libvirt (and people's scripts) use maxcpus only when they want CPU hotplug, so making max_cpus > smp_cpus enable CPU hotplug implicitly would probably solve the compatibility issue.
Libvirt uses maxcpus only if the configuration explicitly has less active cpus than the maximum number. This option would be the best IMO.
If we want to deprecate the use of maxcpus to enable CPU hotplug, then we can make it print a warning for a few releases, so people have time to update their code.
At that point libvirt also needs a way to detect that the new argument is supported by qemu, so we can start passing it on the command line basically every time we now pass 'maxcpus'.
The warning will get most probably ignored by people using libvirt as the stdout/err of qemu is not visible to them. Ok, to make things less complicated I'll drop machine.cpu-hotplug and leave it always enabled as it used to be and as Michael suggested.
I'll drop following patches: 12, 13, 14, 20, 23 and respin series
I actually don't mind disabling it. But I'd be glad if it was based on the max_cpus value as Eduardo suggested. I've already dropped it, and simplifies series quite a bit. So lets continue without disabling for now. Later we can consider disabling it if we agree on conditions when it should happen.
smp_cpus < max_cpus is not a good enough I think:
On Wed, 11 May 2016 15:50:39 +0200 Igor Mammedov <imammedo@redhat.com> wrote:
On Tue, 10 May 2016 17:24:14 -0300 Eduardo Habkost <ehabkost@redhat.com> wrote: [...]
Should max_cpus > smp_cpus automatically set cpu-hotplug=on? I'd prefer dumb explicit feature enablement, as it doesn't put any assumptions on other options and QEMU + mgmt don't have to maintain logic for implicit rules that might enable it.
and if I didn't manage to push 'device_add x86cpu' in 2.7 time frame, guess work gets a bit confusing with current cpu-add semantic, consider current:
SRC-QEMU -smp 1,maxcpus=2 cpu-add 1 DST-QEMU -smp 2,maxcpus=2
vs would be device_add:
SRC-QEMU -smp 1,maxcpus=2 device_add cpu DST-QEMU -smp 1,maxcpus=2 -device cpu
so instead of qemu/users guessing, I suggest to make it explictly enabled to get feature (which is mostly optional) or cleanly fail qemu start if confusing options are specified with a clear error message.