openstack cinder 双ceph后端之间的卷迁移操作
1、前置条件
已为cinder配置好双ceph后端，配置过程见openstack cinder对接两个ceph后端配置
2、卷类型相同的卷迁移
页面上的卷迁移，走的是migrate_volume接口。
入口在cinder/api/contrib/admin_actions.py:VolumeAdminController._migrate_volume
客户端操作命令是：
cinder migrate [--force-host-copy [[True|False]]] [--lock-volume [[True|False]]] [volume] [host]
该操作方法的限制条件是：在卷类型相同的两个后端之间迁移，无论它们是否位于相同的Cinder-Volume主机上。即这个卷的卷类型可以对应要进行迁移的两个后端，如卷类型是rbd的卷，可以在controller@rbd和controller@rbd232两个存储host创建，具体在哪个上边根据调度决定。这样创建出来的卷，在两个后端之间互相迁移没有问题。否则不会迁移，为何不会迁移见源码分析
Cinder/scheduler/manager.py:SchedulerManager.migrate_volume
Cinder/scheduler/filter_scheduler.py:FilterScheduler.backend_passes_filters
_get_weighted_candidates 中核心代码如下：
Cinder/scheduler/host_manager.py:HostManager.get_filtered_backends
Cinder/scheduler/base_filter.py:BaseFilterHandler.get_filtered_objects
Cinder/scheduler/base_filter.py:BaseFilter.filter_all
cinder/scheduler/filters/init.py:BaseBackendFilter._filter_one
Cinder/scheduler/filters/capabilities_filter.py:CapabilitiesFilter.backend_passes
Cinder/scheduler/filters/capabilities_filter.py:CapabilitiesFilter._satisfies_extra_specs
这里的cap_value是存储后端中的volume_backend_name，req是原卷的volume_backend_name。二者相等返回True，说明该节点可用，否则返回False，去掉该节点。
也就是这里判断了该卷的卷类型能否对应两个后端，如果卷类型是rbd232，该卷类型不能对应两个后端，那就无法进行这种迁移操作。
内容比较绕，核心还是卷类型和存储后端的关系
3、卷类型不同的卷迁移
命令行操作（本质上是修改卷的卷类型，在修改类型的过程中进行迁移操作）
cinder retype --migration-policy on-demand [volume] [volume-type]
修改卷类型时，如果要变更的卷类型对应所有后端[rbd232]与原后端[rbd]不同，就会发生迁移。如果要变更的卷类型对应所有后端[rbd232, rbd]与原后端[rbd]有重叠，就不会发生迁移，只是修改卷类型，之后再在管理员页面操作该卷迁移到对应节点上（此时的情况就是卷类型相同的后端之间迁移，与上一种情况相同）
操作流程：
命令行中加的on-demand参数就是按需。修改卷类型后如果需要迁移，就会自动开启迁移。
参考链接
https://platform9.com/kb/openstack/how-to-migrate-volumes-using-cli