On 2026-03-24 6:00 PM, Peter Krempa wrote:
[..]
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.
Makes sense. However, in (admittedly) simple cases where individual
vcpus are not marked as "hotpluggable", with simple xml descriptions
like these-
<vcpu placement='static' current='2'>4</vcpu>
there will be no individual "ID" to explicitly pick. But in more
"traditional" deployments where these policies are explicitly defined
for each vcpu, it makes a lot more sense to use the ID directly.
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.
I'm not a huge fan of doing this to the setvcpus subcommand, since
expressing partial failure becomes non-trivial - there will effectively
be different behaviours for the sync and the async paths in case of
partial failures, which can get confusing to someone who is already used
to the existing mode this subcommand operates.
The reason for this difference could of course be documented (and is
perfectly valid given the semantics), but is that kind of functionality
acceptable for an existing subcommand?
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>
I'll change the implementation to use a new event instead - makes it
easier for a listening application to filter for this specific event,
instead of filtering through event aliases if the existing event was reused.
