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>
