On Mon, Jul 15, 2013 at 04:26:10PM -0400, John Ferlan wrote:
Use the privileged value in order to generate a connection which
could
be passed to the various storage backend drivers.
In particular, the iSCSI driver will need a connect in order to perform
pool authentication using the 'chap' secrets. Additionally, the RBD backend
utilizes the connection during pool refresh for pools using 'ceph' secrets.
---
src/conf/storage_conf.h | 1 +
src/storage/storage_driver.c | 19 +++++++++++++++----
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/src/conf/storage_conf.h b/src/conf/storage_conf.h
index fd9b2e7..62ff1fd 100644
--- a/src/conf/storage_conf.h
+++ b/src/conf/storage_conf.h
@@ -354,6 +354,7 @@ struct _virStorageDriverState {
char *configDir;
char *autostartDir;
+ bool privileged;
};
typedef struct _virStoragePoolSourceList virStoragePoolSourceList;
diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
index a8eb731..f38acef 100644
--- a/src/storage/storage_driver.c
+++ b/src/storage/storage_driver.c
@@ -68,6 +68,13 @@ static void storageDriverUnlock(virStorageDriverStatePtr driver)
static void
storageDriverAutostart(virStorageDriverStatePtr driver) {
size_t i;
+ virConnectPtr conn = NULL;
+
+ if (driverState->privileged)
+ conn = virConnectOpen("qemu:///system");
+ else
+ conn = virConnectOpen("qemu:///session");
+ /* Ignoring NULL conn - let backends decide */
Nope, this doesn't fly. The storage driver is shared across many other
hypervisor drivers, and we can't assume that the QEMU driver is compiled
into libvirt.
IIUC, the reason we need the connection is to access the secrets driver.
We should probably just make the storage driver directly call into the
secrets driver, instead of going via a virConnectPtr object.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|