On Tue, Sep 01, 2015 at 08:55:58PM -0400, John Ferlan wrote:
In an NFS root-squash environment it was possible that if the just
created volume from XML wasn't properly created with the right
uid/gid and/or mode, then the followup refreshVol will fail to open
the volume in order to get the allocation/capacity values. This would
leave the volume still on the server and cause a libvirtd crash because
'voldef' would be in the pool list, but the cleanup code would free it.
It would be nice to blame the commit that broke this, released in 1.2.14:
commit 155ca616eb231181f6978efc9e3a1eb0eb60af8a
Allow creating volumes with a backing store but no capacity
(preferably without mentioning the author's name ;)
Also, is there a bug that can be made public and linked here?
Jan
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
src/storage/storage_driver.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
index ea7e0f3..0494e5d 100644
--- a/src/storage/storage_driver.c
+++ b/src/storage/storage_driver.c
@@ -1867,8 +1867,12 @@ storageVolCreateXML(virStoragePoolPtr obj,
}
if (backend->refreshVol &&
- backend->refreshVol(obj->conn, pool, voldef) < 0)
+ backend->refreshVol(obj->conn, pool, voldef) < 0) {
+ storageVolDeleteInternal(volobj, backend, pool, voldef,
+ 0, false);
+ voldef = NULL;
goto cleanup;
+ }
/* Update pool metadata ignoring the disk backend since
* it updates the pool values.
--
2.1.0
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list