Understood, thanks for the info. How would this then work for cpu hotunplug operations? Since aliases cannot be assigned to individual vcpus, virDomainDetachDeviceAlias cannot be used in that case. Is the caller still expected to wait for the same device_deleted event in case the virDomainSetVcpusFlags call times out, and any additional timeout can be adjusted in the client application as required? This would somewhat mirror the semantics of the async API you've mentioned earlier.
If I were to take the case of qemu: qemuDomainHotplugDelVcpu clubs both failures and timeouts in the same error code (-1). So there does not appear to be a way to actually identify if the request just timed out, or there was an error during the operation, due to which its caller (qemuDomainSetVcpusLive) only sees a return of (-1) and bubbles the same error code down the stack. This is a problem if the application is expected to wait for the event, akin to the async API. Any insight into this would be extremely helpful. 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.
