在Cinder中有六个API调用与卷的挂载/卸载相关联，每个操作有3个调用。
一、挂载/卸载操作是有多条命令组成
在挂载/卸载调用的工作流程中，发生了三类事情
1)更新数据库中卷的状态(例如：attaching/detaching状态)
对于挂载操作，对应的方法为cinder.volume.api.reserve_volume
对于卸载操作，对应的方法为cinder.volume.api.begin_detaching
2)处理需要在卷上执行的连接操作
对于挂载操作,对应的方法为cinder.volume.api.initialize_connection
对于卸载操作，对应的方法为cinder.volume.api.terminate_connection
3)确定卷的状态并释放资源
对于挂载操作，对应的方法为cinder.volume.api.attach
对于卸载操作，对应的方法为cinder.volume.api.detach
二、挂载流程涉及的api
1)reserve_volume(self, context, volume)
此方法仅检查指定的卷是否处于“available”状态及是否可以挂载。任何其他状态都会导致错误响应，并通知Nova，卷不可用。成功调用该api的唯一有效状态是“available”。
对于multi-attach，将在上述可接受状态中添加“in-use”。如果卷实际上是available，将立即向Cinder数据库发出更新，并将卷的状态标记为“attaching”，从而保留卷，
使其不会被其他任何API调用使用
2)initialize_connection(self, context, volume, connector)
这是唯一一个应该执行任何重要工作的挂载相关的API调用。该方法负责构建和返回调用者(nova)所需的所有信息，去实际的将特定的卷挂载到远程节点。
这个方法将重要的信息返回给调用者，这些信息包括 CHAP凭证、iqn和lun信息.
一个响应示例：
{
'driver_volume_type': 'iscsi',
'data': {
'auth_password': 'YZ2Hceyh7VySh5HY',
'target_discovered': False,
'encrypted': False,
'qos_specs': None,
'target_iqn': 'iqn.2010-10.org.openstack:volume-8b1ec3fe-8c57-45ca-a1cf-a481bfc8fce2',
'target_portal': '11.0.0.8:3260',
'volume_id': '8b1ec3fe-8c57-45ca-a1cf-a481bfc8fce2',
'target_lun': 1,
'access_mode': 'rw',
'auth_username': 'nE9PY8juynmmZ95F7Xb7',
'auth_method': 'CHAP'
}
}
在构建此数据结构的过程中，Cinder卷管理器对后端驱动程序进行多次调用，并在数据库中构建volume_attachment条目，以存储通过 connector 对象传入的连接信息
driver.validate_connector
简单的验证initiator数据包含在connector中。有些驱动程序，使用connector的部分数据
driver.create_export
这是与卷关联的特定于目标的持久数据。此方法负责构建实际的iSCSI target，并提供“位置”和“身份验证”信息，这些信息将用于在父请求中形成响应数据。
我们将其称为infor model_update，用于更新Cinder数据库中与卷关联的target信息。
driver.initialize_connection
现在我们已经构建了一个target，并保存了与之相关的重要信息。我们已经准备好将target实际分配到一个卷中，并形成所需的信息以传递回调用者。
这就是我们最终将所有内容放在一起并形成前面显示的示例数据结构响应的地方。它对我们在create_export调用中放在一起的数据进行了大量格式化。
但它并不提供任何新的信息。它完全依赖于在create_export调用中收集并放入数据库的信息。在这一点上，我们所做的就是从数据库中获取所有不同的条目，并将其组合成所需的格式/结构。
更新和获取所有这些信息的关键方法调用由create_export调用完成。然后将格式化的数据传回API，并作为响应传回Nova。
此时，我们将attach信息返回给调用者，它提供了创建远程iSCSI连接所需的一切。
3)attach(self, context, volume, instance_uuid, host_name, mountpoint, mode)
这是最后一个非常简单的调用.这样做的目的是为了完成挂载过程。换句话说，我们只需更新数据库中卷的状态，并提供一种机制来通知驱动程序挂载已成功完成。
三、卸载流程设计的api
1)begin_detaching(self, context, volume)
类似于Attach工作流reserve_volume方法.执行卷状态的简单条件更新为detaching
2)terminate_connection(self, context, volume, connector, force=False)
类似于Attach工作流initialize_connection方法。
用于向drivers/target-drivers发送调用，以执行它们可能需要的任何类型的清理.
对于大多数情况，这是一个noop，因为连接和iscsi会话管理是发起者的职责
然而，这里有许多特殊的情况，特别是对于像LIO这样使用访问组的target-drivers，在这些情况下，它们会在调用期间从访问列表中删除 initiator，从而有效地从目标端关闭会话
3)detach(self, context, volume, attachment_id)
数据库的最终更新，这是又一个将某些内容传递给volume-driver的机会.最初是一个简单的回调，现在在volume-manager中有了相当多的功能.
对于像LVM这样的驱动程序，这也是一个noop，只需更新db条目，将内容标记为完成，并再次将卷设置为available。