Thanks for the review, Daniel. order and the proposed hporder serve related but distinct purposes.
The existing order attribute specifies the sequence in which online vCPU devices are added. During startup, libvirt uses it when realizing initially enabled hotpluggable CPU entities. The domain XML documentation also states: Hypervisors may clear or update ordering information during certain operations to assure valid configuration. The documentation permits `order` to be rewritten as the vCPU configuration changes, where required to assure a valid configuration. At startup, the QEMU driver updates the live ordering to reflect the CPU enable sequence reported by QEMU. - order describes the ordering of enabled CPU devices. Its configured use is during startup, when libvirt realizes the initially enabled hotpluggable CPU entities. - It is not a policy for selecting vCPUs to delete during a count-based decrease. - It does not provide a selection policy for offline vCPUs during a count-based increase. Offline vCPUs do not have a realized insertion order, and their order values may be cleared. - At present, there is no public interface to set a chosen order directly on a live running domain. It can be configured in persistent XML, for example with virsh edit, while live/status XML reflects the realized sequence. The last point could be addressed by adding an interface to change order in a live domain, but that alone would not define the desired count-based selection policy for offline vCPUs. The proposed per-vCPU hporder attribute is intended to provide this separate, administrator-defined policy for dynamic count-based scaling: - during a decrease, eligible hotpluggable CPU entities with the highest removal priority would be selected first; and - during a later increase, eligible disabled entities would be selected in reverse priority order. Unlike order, hporder would remain meaningful for disabled hotpluggable vCPU entities. I agree that the XML documentation could make the distinction clearer. The permission to clear or update ordering information does not explain the difference between realized online-device ordering and a persistent future scaling policy. One possible alternative would be to overload order through a domain-level policy, for example: <vcpu placement='static' current='4' orderpolicy='strict'>8</vcpu> This alternative may be less desirable, since it would allow order to represent runtime ordering in one mode and persistent future policy in another. A separate per-vCPU hporder attribute would preserve the existing order semantics while making the scaling policy explicit. For setvcpu, the caller explicitly selects the vCPU(s) to hotplug or hot-unplug, so hporder would not affect that selection. If the user selects multiple CPU entities with setvcpu, hporder could determine their processing order based on the configured values. Peter and Daniel, I would welcome feedback on the desired setvcpu behavior, as well as the XML representation and proposed API scope.
