[libvirt] [PATCH 6/7] storage: Process storage pool capabilities
Michal Privoznik
mprivozn at redhat.com
Tue Jan 29 10:18:05 UTC 2019
On 1/16/19 2:15 AM, John Ferlan wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1581670
>
> During storage driver backend initialization, let's save
> which backends are available in the storage pool capabilities.
>
> In order to format those, we need add a connectGetCapabilities
> processor to the storageHypervisorDriver. This allows a storage
> connection, such as "storage:///system" to find the API and
> format the results.
>
> NB: This is not available from other hypervisor drivers such as
> QEMU type connections.
>
> Signed-off-by: John Ferlan <jferlan at redhat.com>
> ---
> src/conf/virstorageobj.h | 4 ++++
> src/storage/storage_backend.c | 16 ++++++++++++++++
> src/storage/storage_backend.h | 3 +++
> src/storage/storage_driver.c | 17 +++++++++++++++++
> 4 files changed, 40 insertions(+)
>
> diff --git a/src/conf/virstorageobj.h b/src/conf/virstorageobj.h
> index 1106aa71bd..34adc26df3 100644
> --- a/src/conf/virstorageobj.h
> +++ b/src/conf/virstorageobj.h
> @@ -24,6 +24,8 @@
>
> # include "storage_conf.h"
>
> +# include "capabilities.h"
> +
> typedef struct _virStoragePoolObj virStoragePoolObj;
> typedef virStoragePoolObj *virStoragePoolObjPtr;
>
> @@ -45,6 +47,8 @@ struct _virStorageDriverState {
>
> /* Immutable pointer, self-locking APIs */
> virObjectEventStatePtr storageEventState;
> +
> + virCapsPtr caps;
Would be nice to put a comment here:
/* Immutable pointer, read only after initialized */
> };
>
> typedef bool
> diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
> index a54c338cf0..0ccc616db4 100644
> --- a/src/storage/storage_backend.c
> +++ b/src/storage/storage_backend.c
> @@ -187,3 +187,19 @@ virStorageBackendForType(int type)
> type, NULLSTR(virStoragePoolTypeToString(type)));
> return NULL;
> }
> +
> +
> +virCapsPtr
> +virStorageBackendGetCapabilities(void)
> +{
> + virCapsPtr caps;
> + size_t i;
> +
> + if (!(caps = virCapabilitiesNew(virArchFromHost(), false, false)))
> + return NULL;
> +
The fact that you need to pass virArchFromHost() and false, false means,
that we need to abstract our virCaps even more. I mean, what has the
host architecture has to do with storage capabilities? Moreover, this is
how the beginning of storage caps look like:
# virsh -c storage:///system capabilities
<capabilities>
<host>
<cpu>
<arch>x86_64</arch>
</cpu>
<power_management/>
<iommu support='no'/>
</host>
> + for (i = 0; i < virStorageBackendsCount; i++)
> + virCapabilitiesAddStoragePool(caps, virStorageBackends[i]->type);
> +
> + return caps;
> +}
> diff --git a/src/storage/storage_backend.h b/src/storage/storage_backend.h
> index 2b178494ae..c670c66287 100644
> --- a/src/storage/storage_backend.h
> +++ b/src/storage/storage_backend.h
> @@ -126,4 +126,7 @@ int virStorageBackendDriversRegister(bool allmodules);
>
> int virStorageBackendRegister(virStorageBackendPtr backend);
>
> +virCapsPtr
> +virStorageBackendGetCapabilities(void);
> +
> #endif /* LIBVIRT_STORAGE_BACKEND_H */
> diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
> index 4a13e90481..04beff6b07 100644
> --- a/src/storage/storage_driver.c
> +++ b/src/storage/storage_driver.c
> @@ -300,6 +300,9 @@ storageStateInitialize(bool privileged,
>
> driver->storageEventState = virObjectEventStateNew();
>
> + if (!(driver->caps = virStorageBackendGetCapabilities()))
> + goto error;
> +
Initially, I suspected that we want to refresh the caps on every 'virsh
capabilities' (just like we're doing in say qemu driver). But this is
different because we wouldn't load a storage driver out of the blue
(where as admin might install new qemu binaries once we're running).
Makes sense.
Michal
More information about the libvir-list
mailing list