If for some reason a volume cannot be built in the pool (eg, the
buildVol call fails), then the error code may or may not properly
remove the volume from the pool->volumes.objs[] list.
Removal from the list is dependent on the 'deleteVol()' being present
in the backend *and* calling it returning success. If either failed,
then the volobj would never be removed from the list until a pool
refresh was done (or libvirtd restarted).
Note: This is true prior to commit id '0c2305b3' as well where
the cleanup would have been called prior to removal, but removal
never occurred due to various goto statements.
Since the volume would have been added to the list prior to the
attempt to build the volume, modify the storageVolDeleteInternal()
to perform removal during cleanup.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
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 542b382..789744f 100644
--- a/src/storage/storage_driver.c
+++ b/src/storage/storage_driver.c
@@ -1581,6 +1581,9 @@ storageVolDeleteInternal(virStorageVolPtr obj,
pool->def->available += vol->target.allocation;
}
+ ret = 0;
+
+ cleanup:
for (i = 0; i < pool->volumes.count; i++) {
if (pool->volumes.objs[i] == vol) {
VIR_INFO("Deleting volume '%s' from storage pool
'%s'",
@@ -1591,9 +1594,6 @@ storageVolDeleteInternal(virStorageVolPtr obj,
break;
}
}
- ret = 0;
-
- cleanup:
return ret;
}
--
1.9.0