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)
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.
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. 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
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 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?
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.
