The cinder.volume.drivers.ibm.ibm_storage.xiv_proxy Module¶

class XIVProxy(storage_info, logger, exception, driver=None, active_backend_id=None, host=None)¶

Bases: cinder.volume.drivers.ibm.ibm_storage.proxy.IBMStorageProxy

Proxy between the Cinder Volume and Spectrum Accelerate Storage.

Supports IBM XIV, Spectrum Accelerate, A9000, A9000R Version: 2.1.0 Required pyxcli version: 1.1.5

2.0 - First open source driver version
2.1.0 - Support Consistency groups through Generic volume groups
      - Support XIV/A9000 Volume independent QoS
      - Support groups replication

check_for_splitbrain(volumes, pool_master, pool_slave)¶

create_cloned_volume(volume, src_vref)¶

Create cloned volume.

create_group(context, group)¶

Creates a group.

create_group_from_src(context, group, volumes, group_snapshot, sorted_snapshots, source_group, sorted_source_vols)¶

Create volume group from volume group or volume group snapshot.

create_group_snapshot(context, group_snapshot, snapshots)¶

Create volume group snapshot.

create_snapshot(snapshot)¶

create snapshot.

create_volume(volume)¶

Creates a volume.

create_volume_from_snapshot(volume, snapshot)¶

create volume from snapshot.

delete_group(context, group, volumes)¶

Deletes a group.

delete_group_snapshot(context, group_snapshot, snapshots)¶

Delete volume group snapshot.

delete_snapshot(snapshot)¶

delete snapshot.

delete_volume(volume)¶

Deletes a volume on the Storage machine.

disable_replication(context, group, volumes)¶

disables CG replication

enable_replication(context, group, volumes)¶

Enable cg replication

extend_volume(volume, new_size)¶

Resize volume.

failover_host(context, volumes, secondary_id, groups=None)¶

Failover a full backend.

Fails over the volume back and forth, if secondary_id is ‘default’, volumes will be failed back, otherwize failed over.

Note that the resulting status depends on the direction: in case of failover it will be ‘failed-over’ and in case of failback it will be ‘available’

failover_replication(context, group, volumes, secondary_backend_id)¶

Failover a cg with all it’s volumes.

if secondery_id is default, cg needs to be failed back.

freeze_backend(context)¶

Notify the backend that it’s frozen.

get_replication_status(context, volume)¶

Return replication status.

get_secondary_backend_id(secondary_backend_id)¶

handle_created_vol_properties(replication_info, volume)¶

initialize_connection(volume, connector)¶

Initialize connection to instance.

Maps the created volume to the nova volume node, and returns the iSCSI target to be used in the instance

manage_volume(volume, reference)¶

Brings an existing backend storage object under Cinder management.

reference value is passed straight from the get_volume_list helper function. it is up to the driver how this should be interpreted. It should be sufficient to identify a storage object that the driver should somehow associate with the newly-created cinder volume structure. There are two ways to do this:

1. Rename the backend storage object so that it matches the, volume[‘name’] which is how drivers traditionally map between a cinder volume and the associated backend storage object.
2. Place some metadata on the volume, or somewhere in the backend, that allows other driver requests (e.g. delete, clone, attach, detach…) to locate the backend storage object when required.

If the reference doesn’t make sense, or doesn’t refer to an existing backend storage object, raise a ManageExistingInvalidReference exception.

The volume may have a volume_type, and the driver can inspect that and compare against the properties of the referenced backend storage object. If they are incompatible, raise a ManageExistingVolumeTypeMismatch, specifying a reason for the failure.

manage_volume_get_size(volume, reference)¶

Return size of volume to be managed by manage_volume.

When calculating the size, round up to the next GB.

migrate_volume(context, volume, host)¶

Migrate volume to another backend.

Optimize the migration if the destination is on the same server.

If the specified host is another back-end on the same server, and the volume is not attached, we can do the migration locally without going through iSCSI.

Storage-assisted migration…

retype(ctxt, volume, new_type, diff, host)¶

Change volume type.

Returns a boolean indicating whether the retype occurred.

Parameters:	ctxt – Context volume – A dictionary describing the volume to migrate new_type – A dictionary describing the volume type to convert to diff – A dictionary with the difference between the two types host – A dictionary describing the host to migrate to, where host[‘host’] is its name, and host[‘capabilities’] is a dictionary of its reported capabilities

setup(context)¶

Driver setup.

terminate_connection(volume, connector)¶

Terminate connection.

Unmaps volume. If this is the last connection from the host, undefines the host from the storage.

thaw_backend(context)¶

Notify the backend that it’s unfrozen/thawed.

unmanage_volume(volume)¶

Removes the specified volume from Cinder management.

Does not delete the underlying backend storage object.

update_group(context, group, add_volumes=None, remove_volumes=None)¶

Updates a group.

volume_exists(volume)¶

Checks if a volume exists on xiv.