On Mon, Feb 23, 2026 at 22:39:42 -0300, Lucas Amaral wrote:
storagePoolUndefine(), storagePoolDestroy(), storagePoolDelete(), and storagePoolRefresh() all report VIR_ERR_INTERNAL_ERROR when a pool has asynchronous jobs running. This error code implies a bug in libvirt, but the condition is a normal transient state that occurs during concurrent volume creation.
Change the error code to VIR_ERR_OPERATION_INVALID, which is consistent with the adjacent checks for "pool is not active" and "pool is starting up" in the same functions.
Signed-off-by: Lucas Amaral <lucaaamaral@gmail.com> --- Build-tested on CentOS Stream 9 (297 OK, 0 failures).
Validated by reproducing the async jobs error using LD_PRELOAD to inject a 15-second delay into fallocate64() for pool directory files (fallocate is instant on local filesystems, making the race window too narrow to hit otherwise). With this patch:
Before: error: internal error: pool 'default' has asynchronous jobs running.
After: error: Requested operation is not valid: pool 'default' has asynchronous jobs running.
src/storage/storage_driver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index e19e032427..8f5c921157 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -868,7 +868,7 @@ storagePoolUndefine(virStoragePoolPtr pool) }
if (virStoragePoolObjGetAsyncjobs(obj) > 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, + virReportError(VIR_ERR_OPERATION_INVALID, _("pool '%1$s' has asynchronous jobs running."), def->name); goto cleanup;
The change itself makes sense. Internal error is terrible. As of such I'll push it as is. Reviewed-by: Peter Krempa <pkrempa@redhat.com> But this code really needs a refactor where this logic including the error reporting will be encapsulated into a function, rather than open-coding it.