Hi Daniel,
The last version of my patch fixed bug #611823 prohibit pools with duplicate
storage,
you gave some comments that should do check by source info instead of target
path I used.
These days I view the code and existing documents about storage pool, and tried
to
code based on your comments, but looks like it is turning out to be more
complex.
First, I think it is possible to make clear what it means for a pool to be a
duplicate.
Below is the detailed source info be used for each type of pool according to
the existing
documents and the main item to control.
For details of each type of pool:
VIR_STORAGE_POOL_DIR, /* For dir type, use source->dir only(But in the
code and
example XML file,it use target path).*/
A pool with a type of dir provides the means to manage files within a directory.
VIR_STORAGE_POOL_FS, /* For fs type, use source->device->path.*/
This is a variant of the directory pool. Instead of creating a directory on an
existing mounted filesystem though, it expects a source block device to be
named.
This block device will be mounted and files managed in the directory of its
mount point.
VIR_STORAGE_POOL_NETFS, /* For netfs, use host name and source->dir */
This is a variant of the filesystem pool. Instead of requiring a local block
device as
the source, it requires the name of a host and path of an exported directory.
It will
mount this network filesystem and manage files within the directory of its
mount point.
VIR_STORAGE_POOL_LOGICAL, /* For logical, use source->device->path. */
This provides a pool based on an LVM volume group. For a pre-defined LVM volume
group,
simply providing the group name is sufficient,while to build a new group
requires
providing a list of source devices to serve as physical volumes.
VIR_STORAGE_POOL_DISK, /* For disk type, use source->device->path.*/
This provides a pool based on a physical disk. Volumes are created by adding
partitions to the disk.
VIR_STORAGE_POOL_ISCSI, /* For ISCSI type, use source->device->path. */
This provides a pool based on an iSCSI target.
VIR_STORAGE_POOL_SCSI, /* For SCSI type, use source->adapter name. */
This provides a pool based on a SCSI HBA.
VIR_STORAGE_POOL_MPATH,
This provides a pool that contains all the multipath devices on the host.
Volume creating is not supported via the libvirt APIs, so we will just
ignore this type.
After a preliminary investigation, for source element,
source->device->path,
-Pool type: fs, logical, disk, ISCSI.
-May only occur once.
source->dir,
-Pool type: dir, netfs.
-May only occur once.
source->adapter
-Pool type: SCSI.
-May only occur once.
are the main required location info, and we can control the duplicate storage
based on these three item above for related type of pool.
Second, I have tried to do check by source info for a test, when I debug, I
found
that pools->objs[]->def->source.* which come from virConnectPtr where all
existing
pools info be keeped == NULL, but the current target pool virStoragePoolDefPtr
def
can get source field value, so I think libvirt didn't get source field info in
the
pools list where we do check at all today.
Do you think we should do check based on this? Or any comments for question one
and
two. After you confirmed then I will work on code. Thank you.
--
Lei
--
libvir-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvir-list
