On 2026-03-20 9:29 PM, Peter Krempa wrote:
I did a quick test with `virsh event` (using libvirt 9.x and qemu 7.2.0), and
cpu
hotunplug events do not seem to make it to virsh. I can confirm it's definitely
registered for the event because I can see the same event for other alias-based
detachment operations that I try (e.g. disk/iface) in the same invocation. The
libvirtd
log however includes the successful event that it received. Not *very* relevant
to the
discussion at the moment, just thought I'd mention it to see if I was doing
something wrong.
Ah, no you are doing things correctly here. Unfortunately we indeed
don't send out the device-deleted event on cpu unplug.
Was that intentional or merely an oversight?
I don't remember any more. Might have been semi-intentional as we dont'
really have guest XML visible aliases for CPUs. So it might need a new
event type to handle this case properly.
Regardless, I've since fixed this; an event is now emitted (to a valid
application that is registered as a listener with libvirt) whenever a vcpu
gets hot-unplugged. Verifiable through `virsh event` invocations on the CLI.
Or reuse this event but then we IMO should add aliases to the
hotpluggable and enabled vCPU entities.
Yes, this is what I've done - the `device-removed` event gets
broadcasted when a hot-unplug occurs. Makes it more uniform with the
other hot-unplug events.
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 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 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 identify the hotpluggable CPUs with the
`info hotpluggable-cpus` QMP command anyway.
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 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?
