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
