The cinder.volume.manager Module

Volume manager manages creating, attaching, detaching, and persistent storage.

Persistent storage volumes keep their state independent of instances. You can attach to an instance, terminate the instance, spawn a new instance (even one from a different image) and re-attach the volume with the same data intact.

Related Flags

volume_topic:What rpc topic to listen to (default: cinder-volume). volume_manager:The module name of a class derived from manager.Manager (default: cinder.volume.manager.Manager). volume_driver:Used by Manager. Defaults to cinder.volume.drivers.lvm.LVMVolumeDriver. volume_group:Name of the group that will contain exported volumes (default: cinder-volumes) num_shell_tries:  Number of times to attempt to run commands (default: 3)

class VolumeManager(volume_driver=None, service_name=None, *args, **kwargs)

Bases: cinder.manager.SchedulerDependentManager

Manages attachable block storage devices.

RPC_API_VERSION = '1.30'

accept_transfer(context, volume_id, new_user, new_project)

attach_volume(context, volume_id, instance_uuid, host_name, mountpoint, mode)

Updates db to show volume is attached.

copy_volume_to_image(context, volume_id, image_meta)

Uploads the specified volume to Glance.

image_meta is a dictionary containing the following keys: ‘id’, ‘container_format’, ‘disk_format’

create_cgsnapshot(context, group, cgsnapshot_id)

Creates the cgsnapshot.

create_consistencygroup(context, group)

Creates the consistency group.

create_consistencygroup_from_src(context, group, cgsnapshot_id=None, source_cg=None)

Creates the consistency group from source.

The source can be a CG snapshot or a source CG.

create_snapshot(context, volume_id, snapshot)

Creates and exports the snapshot.

create_volume(context, volume_id, request_spec=None, filter_properties=None, allow_reschedule=True)

Creates the volume.

delete_cgsnapshot(context, cgsnapshot_id)

Deletes cgsnapshot.

delete_consistencygroup(context, group)

Deletes consistency group and the volumes in the group.

delete_snapshot(inst, context, snapshot, **kwargs)

delete_volume(inst, context, volume_id, **kwargs)

detach_volume(inst, context, volume_id, attachment_id=None, **kwargs)

disable_replication(context, volume)

Disable replication on the specified volume.

If the specified volume is currently replication enabled, this method can be used to disable the replication process on the backend. This method assumes that we checked replication status in the API layer to ensure we should send this call to the driver.

Parameters:

• context – security context
• volume – volume object returned by DB

enable_replication(context, volume)

Enable replication on a replication capable volume.

If the volume was created on a replication_enabled host this method is used to enable replication for the volume. Primarily used for testing and maintenance.

Parameters:

• context – security context
• volume – volume object returned by DB

extend_volume(context, volume_id, new_size, reservations)

failover_replication(context, volume, secondary=None)

Force failover to a secondary replication target.

Forces the failover action of a replicated volume to one of its secondary/target devices. By default the choice of target devices is left up to the driver. In particular we expect one way replication here, but are providing a mechanism for ‘n’ way if supported/configrued.

Currently we leave it up to the driver to figure out how/what to do here. Rather than doing things like ID swaps, we instead just let the driver figure out how/where to route things.

In cases where we might want to drop a volume-service node and the replication target is a configured cinder backend, we’ll just update the host column for the volume.

Parameters:

• context – security context
• volume – volume object returned by DB
• secondary – Specifies rep target to fail over to

get_capabilities(context, discover)

Get capabilities of backend storage.

init_host()

Perform any required initialization.

initialize_connection(context, volume_id, connector)

Prepare volume for connection from host represented by connector.

This method calls the driver initialize_connection and returns it to the caller. The connector parameter is a dictionary with information about the host that will connect to the volume in the following format:

{
    'ip': ip,
    'initiator': initiator,
}

ip: the ip address of the connecting machine

initiator: the iscsi initiator name of the connecting machine. This can be None if the connecting machine does not support iscsi connections.

driver is responsible for doing any necessary security setup and returning a connection_info dictionary in the following format:

{
    'driver_volume_type': driver_volume_type,
    'data': data,
}

driver_volume_type: a string to identify the type of volume. This

can be used by the calling code to determine the strategy for connecting to the volume. This could be ‘iscsi’, ‘rbd’, ‘sheepdog’, etc.

data: this is the data that the calling code will use to connect

to the volume. Keep in mind that this will be serialized to json in various places, so it should not contain any non-json data types.

is_working()

Return if Manager is ready to accept requests.

This is to inform Service class that in case of volume driver initialization failure the manager is actually down and not ready to accept any requests.

list_replication_targets(context, volume)

Provide a means to obtain replication targets for a volume.

This method is used to query a backend to get the current replication config info for the specified volume.

In the case of a volume that isn’t being replicated, the driver should return an empty list.

Example response for replicating to a managed backend:

{‘volume_id’: volume[‘id’],

‘targets’:[{‘managed_host’: ‘backend_name’}...]

Example response for replicating to an unmanaged backend:

{‘volume_id’: volume[‘id’], ‘targets’:[{‘san_ip’: ‘1.1.1.1’,

‘san_login’: ‘admin’}, ....]}

NOTE: It’s the responsibility of the driver to mask out any passwords or sensitive information.

manage_existing(ctxt, volume_id, ref=None)

manage_existing_snapshot(ctxt, snapshot, ref=None)

migrate_volume(ctxt, volume_id, host, force_host_copy=False, new_type_id=None)

Migrate the volume to the specified host (called on source host).

migrate_volume_completion(ctxt, volume_id, new_volume_id, error=False)

promote_replica(ctxt, volume_id)

Promote volume replica secondary to be the primary volume.

publish_service_capabilities(context)

Collect driver status and then publish.

reenable_replication(ctxt, volume_id)

Re-enable replication of secondary volume with primary volumes.

remove_export(context, volume_id)

Removes an export for a volume.

retype(ctxt, volume_id, new_type_id, host, migration_policy='never', reservations=None)

target = <Target version=1.30>

terminate_connection(context, volume_id, connector, force=False)

Cleanup connection from host represented by connector.

The format of connector is the same as for initialize_connection.

update_consistencygroup(context, group, add_volumes=None, remove_volumes=None)

Updates consistency group.

Update consistency group by adding volumes to the group, or removing volumes from the group.

update_migrated_volume(ctxt, volume, new_volume, volume_status)

Finalize migration process on backend device.

locked_detach_operation(f)

Lock decorator for volume detach operations.

Takes a named lock prior to executing the detach call. The lock is named with the operation executed and the id of the volume. This lock can then be used by other operations to avoid operation conflicts on shared volumes.

This locking mechanism is only for detach calls. We can’t use the locked_volume_operation, because detach requires an additional attachment_id in the parameter list.

locked_snapshot_operation(f)

Lock decorator for snapshot operations.

Takes a named lock prior to executing the operation. The lock is named with the operation executed and the id of the snapshot. This lock can then be used by other operations to avoid operation conflicts on shared snapshots.

Example use:

If a snapshot operation uses this decorator, it will block until the named lock is free. This is used to protect concurrent operations on the same snapshot e.g. delete SnapA while create volume VolA from SnapA is in progress.

locked_volume_operation(f)

Lock decorator for volume operations.

Takes a named lock prior to executing the operation. The lock is named with the operation executed and the id of the volume. This lock can then be used by other operations to avoid operation conflicts on shared volumes.

Example use:

If a volume operation uses this decorator, it will block until the named lock is free. This is used to protect concurrent operations on the same volume e.g. delete VolA while create volume VolB from VolA is in progress.