On Mon, Mar 23, 2026 at 11:22:20 +0530, Akash Kulhalli wrote:
On 2026-03-20 9:29 PM, Peter Krempa wrote:
[...]
Specifically 'processDeviceDeletedEvent' calls 'qemuDomainRemoveVcpuAlias' which doesn't actually fire off an event. I guess we could either define an schema for aliases for vCPUs to use
I've tweaked the alias lookup so that it also looks at newly-refreshed vcpu definitions for the qemu-defined aliases for domain vcpus. Which means an async hotplug through `virsh device-detach-alias <vcpu-alias>` is now possible. This has the handy benefit of having application-configurable timeouts for the unplug event to arrive, with the timeouts now being the caller applications' concern.
That is okay as long as you introduce the alias in the XML for the vCPUs so that the user doesn't have to guess.
A user can choose which cpu alias to unplug based on the output of `virsh vcpuinfo`. But this of course has the shortcoming that these `vcpuN` ids are
Well, the user ought to use 'virsh setvcpu' and the corresponding underlying API to do the unplug. e.g. do not try to add CPU unplug to `virDomainDetachDeviceAlias`.
not stable, since they can change their cpu mappings based on the order they were plugged/unplugged. Could enhance the output of `virsh vcpuinfo` so that
That is fair. For other devices aliases can be looked up in the XML to see what libvirt has assigned. We just need that also for vcpu objects. The XML should provide place to do this. (Note that aliases are technically "machine ABI", at least in some cases, as qemu uses them to identify the objects in the migration stream. I don't remember if that is the case for vCPU 'devices')
the hotpluggability of each vcpu could also be displayed there to help a user make a more informed decision. A more savvy user could technically
Note that virsh output (unless explicitly mentioned that it's for human consumption) may be used also by scripts. In such case changing the output needs to be done carefully. E.g. adding inactive vcpus to virsh vcpuinfo could break stuff. Adding new fields should be okay.
identify the hotpluggable CPUs with the `info hotpluggable-cpus` QMP command anyway.
'virsh qemu-monitor-command' taints the VM object because users can mess stuff up. This must not be a suggested solution.
Because the qemu-defined aliases are used instead of reworking the xml schema to allow for individual vcpu aliases (which personally is too cumbersome to maintain for large setups), there are two inherent advantages-
Well user-defined aliases don't need to be added to this but we need to expose the values which will be supported in the XML.
I'm not sure I understand - can you elaborate? In the current changeset, I'm
User-defined aliases are the alias in form of 'ua-UserProvidedString' which can be specified by the user. For normal devices libvirt would use that alias if provided. For vCPUs this needs to beimplemented because vCPUs don't use the common parser. Libvirt could allow user aliases for vcpus (e.g. user would have to define them for all - even inactive - vcpus) and you could then use that one. But that would require also modifications to the startup and hotplug code paths to use them. I don't think this is needed. We just need to record the current alias for active vCPUs in the XML so that the user can probe it before trying unplug so that they can wait for the correct event.
reusing the alias that qemu maintains for each vcpu, not defining them anew. Are you saying these aliases should be populated in the live xml?
If you want to use them as the identifier in the event, then yes they must be present in the live XML so that the user can know which alias to expect. If you plan to add a separate event for vcpu unplug (which is also the possibility) then you can do without the alias since you could use the index as defined in the XML to identify the unplugged vcpu.