On Tue, Jan 20, 2026 at 12:21:17 -0000, akash.kulhalli--- via Devel wrote: Please avoid deleting the context. It makes it hard to see the context of your reply.
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
So we have an special API for CPU hot(un)plug 'virDomainSetVcpu' for inidividual CPU hotplug.
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
'virDomainSetVcpusFlags' is not the correct API here because it can attempt to unplug more cpus at once which has uncertain.
can be adjusted in the client application as required? This would somewhat mirror the semantics of the async API you've mentioned earlier.
So while 'virDomainSetVcpu' does have the semi-synchronous behaviour we had with the old-style APIs before we could add a new flag for the API that just skips the call to qemuDomainWaitForDeviceRemoval and qemuDomainRemoveVcpu and just returns success to avoid the possible timeout if that's a problem for your application.
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
Everything will return -1 as failure because that's the RPC's implementation limitation. We do have error codes in the error object though ...
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.
... so while you see a -1 here, the error code will be VIR_ERR_OPERATION_TIMEOUT from this API only in case when the guest OS didn't cooperate.
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.
Ah, no you are doing things correctly here. Unfortunately we indeed don't send out the device-deleted event on cpu unplug. 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 the normal event or introduce another one (quite unpleasant work though).