On Tue, Mar 24, 2026 at 17:13:37 +0530, Akash Kulhalli wrote:
On 2026-03-23 3:12 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`.
Do you mean that the `setvcpu` subcommand be enhanced to additionally accept an alias? Otherwise.. (continued at the end)
No.
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.
I agree - that is additional toil for someone defining the domain xml by hand, without a lot of upside. Doing this also requires careful default considerations for forward-compatibility of any older xmls.
Any old XML needs to work, this would be just optional exactly as with other devices.
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.
(cont.) ..there is little justification to expose the aliases in the live xml, if the aliased-unplug path must not take the `virDomainDetachDeviceAlias` path.
If you decide not to implement a new event and go with the VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED event, which uses alias then you *must* make the alias available to the user. If you decide to add a new event ID which will have an identifier such as the vcpu ID then no aliases need to be exposed. But there must be a way for the user to understand which vCPU was unplugged. The guest OS may decide to release them in arbitrary order. This is orthogonal to how the CPU unplug is triggered and whether `virDomainDetachDeviceAlias` will support it or not. For that matter I don't think it's reasonably viable without too many hacks to integrate CPU unplug into `virDomainDetachDeviceAlias`. Obviously if you want to make it work via `virDomainDetachDeviceAlias`, then again you *must* expose the alias in the XML.
What I've done now is to effectively "short-circuit" an aliased vcpu unplug to the same `setvcpu + --disable` path if the alias resolves to a valid cpuid.
If you'd prefer to discourage the use of `virsh detach-device-alias` for
Regardless of how you trigger the unplug the unplug event must be identifiable.
vcpus, then the setvcpu subcommand could instead be enhanced to accept a `--alias vcpuN` argument. Is that what you had in mind? Or do you want the
No you don't need to do that and also the underlying APIs wouldn't allow passing the alias. Specifically the API is defined as: virDomainSetVcpu(dom, vcpulist, state, flags) or virDomainSetVcpusFlags(dom, count, flags) So no alias can be passed. What I was suggesting is that you add a flag to virDomainSetVcpu which will skip the synchronous part. This will need to be done regardless of if you integrate it with `virDomainDetachDeviceAlias`. Possibly do this also for virDomainSetVcpusFlags, but we can simply document to use the better API instead.
alias to be reflected in the live xml purely so that a user can identify the event alias to wait for when a vcpu is hot-unplugged?
Once again, if you decide to add a new event, alias is not needed. The new event would then identify the vCPUs by 'id' from: <vcpus> <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='no' hotpluggable='yes'/> <vcpu id='7' enabled='no' hotpluggable='yes'/> </vcpus>