This has no implication on the NUMA-pinning dialog but for the record I tested the NUMA-pinning dialog with 700 vNUMA nodes and it works fine
I'll merge the patch that enables up to 710 vCPUs but it's not a complete because without relaxing the restrictions on the supported CPU topology we can't set a 710:1:1 topology - First, the number of sockets is limited to 16 Second, there is a computation in VmCpuCountHelper#calcMaxVCpu that seems to prevent maxVCpus from getting to 710 with this combination Milan, I see that you've added the latter, should it change?
The most comprehensive summary at the time was https://bugzilla.redhat.com/show_bug.cgi?id=1406243#c13. Basically, Intel 8-bit APIC ID limits applied (on x86_64). A newer, x2APIC support was needed to lift the restriction. I'd suggest checking with the platform whether enabling the higher number of vCPUs requires some hardware/emulation features, such as `x2apic' CPU flag, or whether it's automatically possible on hosts that provide that high number of CPUs. Additionally (or alternatively?), looking into BZ 1788991, maybe adding <ioapic driver='qemu'/> to the domain XML is needed?
(In reply to Milan Zamazal from comment #5) > The most comprehensive summary at the time was > https://bugzilla.redhat.com/show_bug.cgi?id=1406243#c13. Basically, Intel > 8-bit APIC ID limits applied (on x86_64). A newer, x2APIC support was needed > to lift the restriction. > I'd suggest checking with the platform whether enabling the higher number of > vCPUs requires some hardware/emulation features, such as `x2apic' CPU flag, > or whether it's automatically possible on hosts that provide that high > number of CPUs. Additionally (or alternatively?), looking into BZ 1788991, > maybe adding <ioapic driver='qemu'/> to the domain XML is needed? Yeah I also see that <apic/> and <ioapic driver='qemu'/> appear in https://bugzilla.redhat.com/show_bug.cgi?id=1840923#c41 If that's what needed to enable this and that's what QEMU test with, maybe we should do it as well So Milan, can you please check that? I took this bug since I thought it's a simple change of a configuration value :)
Milan, is there anything else to change? did we drop the limitation on 16 sockets?
The limitation on 16 sockets hasn't been dropped yet. Technically, it's not necessarily needed for this RFE (it can be compensated with the number of cores) but it would be nice to have and I plan to look at it. Another enhancement may be to improve immediate checks in the VM edit dialog but it's also not strictly necessary.
(In reply to Milan Zamazal from comment #11) > The limitation on 16 sockets hasn't been dropped yet. Technically, it's not > necessarily needed for this RFE (it can be compensated with the number of > cores) but it would be nice to have and I plan to look at it. Another > enhancement may be to improve immediate checks in the VM edit dialog but > it's also not strictly necessary. Ack, thanks So lets keep this bz in POST for now so if we'll do that, QE will test all those changes together (and we won't need to mess with many bugs) When we're ok with the changes that are in for 4.4.8, we'll move it to MODIFIED
It seems VMs with hundreds of sockets can start and I couldn't find any information about limits on the number of CPU sockets, so perhaps we can drop the limit completely. Eduardo, do you know whether it's safe not to limit the number of CPU sockets and allow configurations such as 710 sockets with 1 die, core and thread per socket?
(In reply to Milan Zamazal from comment #13) > It seems VMs with hundreds of sockets can start and I couldn't find any > information about limits on the number of CPU sockets, so perhaps we can > drop the limit completely. > > Eduardo, do you know whether it's safe not to limit the number of CPU > sockets and allow configurations such as 710 sockets with 1 die, core and > thread per socket? We probably won't hit any host-side limits if we do this. I think it makes sense to remove the socket count limitation from management software, but we should keep in mind that this doesn't mean configurations that have no equivalent in real hardware are supposed to work out of the box with all guests.
Since I didn't have hardware with that many CPUs, I verified the attached patches by faking the number of CPUs in Vdsm, like this: https://gerrit.ovirt.org/c/vdsm/+/116206. Although running a strongly overcommitted VM doesn't allow its guest OS to boot up normally, it's good enough for checking whether the VM can be started by QEMU at all with the given number of current/maximum vCPUs and CPU topology.
QE doesn't have hardware to verify this bug. Move this bug to VERIFIED according to Milan's comment #15.
This bugzilla is included in oVirt 4.4.8 release, published on August 19th 2021. Since the problem described in this bug report should be resolved in oVirt 4.4.8 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.