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.