The cinder.volume.drivers.ibm.storwize_svc.storwize_svc_iscsi
Module¶
ISCSI volume driver for IBM Storwize family and SVC storage systems.
Notes: 1. If you specify both a password and a key file, this driver will use the
key file only.
- When using a key file for authentication, it is up to the user or system administrator to store the private key in a safe manner.
- The defaults for creating volumes are “-rsize 2% -autoexpand -grainsize 256 -warning 0”. These can be changed in the configuration file or by using volume types(recommended only for advanced users).
Limitations: 1. The driver expects CLI output in English, error messages may be in a
localized format.
- Clones and creating volumes from snapshots, where the source and target are of different sizes, is not supported.
-
class
StorwizeSVCISCSIDriver
(*args, **kwargs)¶ Bases:
cinder.volume.drivers.ibm.storwize_svc.storwize_svc_common.StorwizeSVCCommonDriver
IBM Storwize V7000 and SVC iSCSI volume driver.
Version history: 1.0 - Initial driver 1.1 - FC support, create_cloned_volume, volume type support,
get_volume_stats, minor bug fixes1.2.0 - Added retype 1.2.1 - Code refactor, improved exception handling 1.2.2 - Fix bug #1274123 (races in host-related functions) 1.2.3 - Fix Fibre Channel connectivity: bug #1279758 (add delim to
lsfabric, clear unused data from connections, ensure matching WWPNs by comparing lower case1.2.4 - Fix bug #1278035 (async migration/retype) 1.2.5 - Added support for manage_existing (unmanage is inherited) 1.2.6 - Added QoS support in terms of I/O throttling rate 1.3.1 - Added support for volume replication 1.3.2 - Added support for consistency group 1.3.3 - Update driver to use ABC metaclasses 2.0 - Code refactor, split init file and placed shared methods for
FC and iSCSI within the StorwizeSVCCommonDriver class2.0.1 - Added support for multiple pools with model update 2.1 - Added replication V2 support to the global/metro mirror
mode2.1.1 - Update replication to version 2.1
-
VERSION
= '2.1.1'¶
-
initialize_connection
(*args, **kwargs)¶ Perform necessary work to make an iSCSI connection.
To be able to create an iSCSI connection from a given host to a volume, we must: 1. Translate the given iSCSI name to a host name 2. Create new host on the storage system if it does not yet exist 3. Map the volume to the host if it is not already done 4. Return the connection information for relevant nodes (in the
proper I/O group)
-
terminate_connection
(*args, **kwargs)¶ Cleanup after an iSCSI connection has been terminated.
When we clean up a terminated connection between a given connector and volume, we: 1. Translate the given connector to a host name 2. Remove the volume-to-host mapping if it exists 3. Delete the host if it has no more mappings (hosts are created
automatically by this driver when mappings are created)
-
validate_connector
(connector)¶ Check connector for at least one enabled iSCSI protocol.
-