The cinder.volume.drivers.ibm.xiv_ds8k Module

Unified Volume driver for IBM XIV and DS8K Storage Systems.

class XIVDS8KDriver(*args, **kwargs)

Bases: cinder.volume.drivers.san.san.SanDriver, cinder.volume.driver.ManageableVD, cinder.volume.driver.ExtendVD, cinder.volume.driver.SnapshotVD, cinder.volume.driver.MigrateVD, cinder.volume.driver.ReplicaVD, cinder.volume.driver.ConsistencyGroupVD, cinder.volume.driver.CloneableVD, cinder.volume.driver.CloneableImageVD, cinder.volume.driver.TransferVD

Unified IBM XIV and DS8K volume driver.

create_cgsnapshot(context, cgsnapshot)

Creates a consistency group snapshot.

create_cloned_volume(tgt_volume, src_volume)

Create Cloned Volume.

create_consistencygroup(context, group)

Creates a consistency group.

create_export(context, volume, connector)

Create an export.

create_replica_test_volume(volume, src_vref)

Creates a test replica clone of the specified replicated volume.

create_snapshot(snapshot)

Create a snapshot.

create_volume(volume)

Create a volume on the IBM XIV and DS8K Storage system.

create_volume_from_snapshot(volume, snapshot)

Create a volume from a snapshot.

delete_cgsnapshot(context, cgsnapshot)

Deletes a consistency group snapshot.

delete_consistencygroup(context, group)

Deletes a consistency group.

delete_snapshot(snapshot)

Delete a snapshot.

delete_volume(volume)

Delete a volume on the IBM XIV and DS8K Storage system.

do_setup(context)

Setup and verify IBM XIV and DS8K Storage connection.

ensure_export(context, volume)

Ensure an export.

extend_volume(volume, new_size)

Extend Created Volume.

get_replication_status(context, volume)

Return replication status.

get_volume_stats(refresh=False)

Get volume stats.

initialize_connection(volume, connector)

Map the created volume.

manage_existing(volume, existing_ref)

Brings an existing backend storage object under Cinder management.

existing_ref is passed straight through from the API request’s manage_existing_ref value, and 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. In the case of XIV, the existing_ref consists of a single field named ‘existing_ref’ representing the name of the volume on the storage.

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 existing_ref 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_existing_get_size(volume, existing_ref)

Return size of volume to be managed by manage_existing.

migrate_volume(context, volume, host)

Migrate the volume to the specified host.

promote_replica(context, volume)

Promote the replica to be the primary volume.

reenable_replication(context, volume)

Re-enable volume replication.

remove_export(context, volume)

Disconnect a volume from an attached instance.

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

Convert the volume to be of the new type.

terminate_connection(volume, connector, **kwargs)

Terminate a connection to a volume.

unmanage(volume)

Removes the specified volume from Cinder management.

Previous topic

The cinder.volume.drivers.ibm.storwize_svc.ssh Module

Next topic

The cinder.volume.drivers.infortrend.eonstor_ds_cli.cli_factory Module

Project Source

This Page