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) |
Bases: cinder.manager.SchedulerDependentManager
Manages attachable block storage devices.
Updates db to show volume is attached.
Uploads the specified volume to Glance.
image_meta is a dictionary containing the following keys: ‘id’, ‘container_format’, ‘disk_format’
Creates the cgsnapshot.
Creates the consistency group.
Creates the consistency group from source.
The source can be a CG snapshot or a source CG.
Creates and exports the snapshot.
Creates the volume.
Deletes cgsnapshot.
Deletes consistency group and the volumes in the group.
Failover a backend to a secondary replication target.
Instructs a replication capable/configured backend to failover to one of it’s secondary replication targets. host=None is an acceptable input, and leaves it to the driver to failover to the only configured target, or to choose a target on it’s own. All of the hosts volumes will be passed on to the driver in order for it to determine the replicated volumes on the host, if needed.
Parameters: |
|
---|
Freeze management plane on this backend.
Basically puts the control/management plane into a Read Only state. We should handle this in the scheduler, however this is provided to let the driver know in case it needs/wants to do something specific on the backend.
Parameters: | context – security context |
---|
Get capabilities of backend storage.
Perform any required initialization.
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,
}
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.
Migrate the volume to the specified host (called on source host).
Promote volume replica secondary to be the primary volume.
Collect driver status and then publish.
Re-enable replication of secondary volume with primary volumes.
Removes an export for a volume.
Cleanup connection from host represented by connector.
The format of connector is the same as for initialize_connection.
UnFreeze management plane on this backend.
Basically puts the control/management plane back into a normal state. We should handle this in the scheduler, however this is provided to let the driver know in case it needs/wants to do something specific on the backend.
Parameters: | context – security context |
---|
Updates consistency group.
Update consistency group by adding volumes to the group, or removing volumes from the group.
Finalize migration process on backend device.
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.
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.
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.