[PATCH 4/4] storage: Handle failure from refreshVol

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
---
 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]