On Thu, Feb 04, 2016 at 08:40:49PM -0500, John Ferlan wrote:
During processing of the extents found in a pool, we have
historically
ignored the thin-pool which means any thin lv found in the pool would
also be ignored. This can start to change now - we can save aside the
name and capacity of any thin-pool's found so that we can use that when
we find a thin lv and fill in the thin-pool capacity value on output.
The result will end up being the following for a vol-dumpxml:
<source>
<thinpool name='thinmints'/>
<capacity unit='bytes'>20971520</capacity>
</thinpool>
</source>
Volume XML should contain information about the volume.
Putting the pool capacity there feels unnatural and out of place.
instead of an empty <source> </source> pair.
An upcoming patch will allow a thin lv to be seen
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
src/conf/storage_conf.h | 12 +++++++++
src/storage/storage_backend_logical.c | 51 +++++++++++++++++++++++++++++++++--
2 files changed, 61 insertions(+), 2 deletions(-)
diff --git a/src/storage/storage_backend_logical.c
b/src/storage/storage_backend_logical.c
index 3044853..d7990e2 100644
--- a/src/storage/storage_backend_logical.c
+++ b/src/storage/storage_backend_logical.c
@@ -72,6 +72,8 @@ virStorageBackendLogicalSetActive(virStoragePoolObjPtr pool,
struct virStorageBackendLogicalPoolVolData {
virStoragePoolObjPtr pool;
virStorageVolDefPtr vol;
+ size_t nthinpools;
+ virStorageVolSourceThinPoolPtr thinpools;
This is literally a list of pools in the pool.
};
static int
@@ -410,9 +441,25 @@
virStorageBackendLogicalFindLVs(virStoragePoolObjPtr pool,
"lvs") < 0)
goto cleanup;
+ /* If we find some thin-pools during processing, let's see if we
+ * need information from them for any thin lv's in the pool
+ */
+ for (i = 0; i < cbdata.nthinpools; i++) {
+ for (j = 0; j < pool->volumes.count; j++) {
+ if (STREQ_NULLABLE(pool->volumes.objs[j]->source.thin_pool,
+ cbdata.thinpools[i].name)) {
+ pool->volumes.objs[j]->source.thin_capacity =
+ cbdata.thinpools[i].capacity;
+ }
+ }
+ }
+
This information should be stored in one place, not n+1 places.
Jan