Peter Krempa wrote:
On Wed, Jul 15, 2026 at 16:11:06 +0100, Daniel P. Berrangé via Devel wrote:
On Wed, Jul 15, 2026 at 02:56:50PM +0530, Partha Satapathy via Devel wrote: The existing per-vCPU 'order' attribute has different semantics and cannot be reused for this purpose. It is used to define the order and grouping of vCPUs when they are enabled. It applies to online vCPUs and is not a policy for selecting offline hotpluggable vCPUs. In particular, 'order' is not used to choose which vCPUs are removed by a count-based `setvcpus` reduction. Therefore, it cannot express an administrator-defined hot-unplug sequence. Aren't you simply describing a bug in the implementation of "order". I defined a guest with # virsh dumpxml --inactive 2 --xpath //vcpu <vcpu placement="static" current="4">8</vcpu> <vcpu id="0" enabled="yes" hotpluggable="no" order="1"/> <vcpu id="1" enabled="yes" hotpluggable="yes" order="2"/> <vcpu id="2" enabled="no" hotpluggable="yes" order="3"/> <vcpu id="3" enabled="no" hotpluggable="yes" order="4"/> <vcpu id="4" enabled="no" hotpluggable="yes" order="5"/> <vcpu id="5" enabled="no" hotpluggable="yes" order="6"/> <vcpu id="6" enabled="yes" hotpluggable="yes" order="7"/> <vcpu id="7" enabled="yes" hotpluggable="yes" order="8"/> Yet when I start this guest, libvirt throws away the order information I configured # virsh setvcpus rhel92 6 # virsh dumpxml rhel92 --xpath //vcpu <vcpu placement="static" current="4">8</vcpu> <vcpu id="0" enabled="yes" hotpluggable="no" order="1"/> <vcpu id="1" enabled="yes" hotpluggable="yes" order="2"/> <vcpu id="2" enabled="no" hotpluggable="yes"/> <vcpu id="3" enabled="no" hotpluggable="yes"/> <vcpu id="4" enabled="no" hotpluggable="yes"/> <vcpu id="5" enabled="no" hotpluggable="yes"/> <vcpu id="6" enabled="yes" hotpluggable="yes" order="3"/> <vcpu id="7" enabled="yes" hotpluggable="yes" order="4"/> and hotplugging CPUs ignores the order I defined # virsh setvcpus rhel92 6 # virsh dumpxml rhel92 --xpath //vcpu <vcpu placement="static" current="6">8</vcpu> <vcpu id="0" enabled="yes" hotpluggable="no" order="1"/> <vcpu id="1" enabled="yes" hotpluggable="yes" order="2"/> <vcpu id="2" enabled="yes" hotpluggable="yes" order="5"/> <vcpu id="3" enabled="yes" hotpluggable="yes" order="6"/> <vcpu id="4" enabled="no" hotpluggable="yes"/> <vcpu id="5" enabled="no" hotpluggable="yes"/> <vcpu id="6" enabled="yes" hotpluggable="yes" order="3"/> <vcpu id="7" enabled="yes" hotpluggable="yes" order="4"/> IMHO, that is just broken and we should fix "order" to be honoured, which would appear to address your use case. Order is currently the effective order that was used to hotplug the devices in so that e.g. on migration the state can be properly restored, so it's used only for active vcpus and ignored for inactive.
Since we have API to hotplug specific vCPU too, this *must* update the order (in order for the migration to stay compatible) so it'd effectively change the "config" if users were able to set the order (e.g. un-set order from another vCPU if it were plugged in out of order).
Effective re-use of 'order' is thus not reallistically feasible in this case.
As I've said in the other thread we do allow hotplug vcpus in arbitrary order, so this would be just syntax-sugar to support hotplug in arbitrary order via the sequenital order API.
I don't feel it's worth keeping this complex logic in libvirt as the use cases are relatively niche and it's a lot of extra complexity to maintain.
Hi Peter, I missed your reply before my last post. I understand that arbitrary vCPU ordering can be achieved by explicitly adding or removing individual vCPUs with setvcpu. This RFC aims to make that process a lot easier. Large data-centre deployments require management layers to repeatedly calculate eligible vCPUs, hotplug groups, NUMA balance, topology, and scale direction. This becomes complex and error-prone. This RFC is an opt-in mechanism to store that selection policy once in XML. It does not impose a balancing policy or change existing behaviour. Would you be open to reconsidering whether this offers sufficient value for standardized, repeatable count-based scaling in libvirt mainline? If not, I understand. Thank you for the feedback; I will not pursue this RFC further. Regards, Partha