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).
