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?