On Thu, 12 May 2016 15:27:04 +0200 Peter Krempa <pkrempa@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: > > > On Tue, 10 May 2016 17:24:14 -0300 > > Eduardo Habkost <ehabkost@xxxxxxxxxx> 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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list