这是Openstack liberty云主机迁移源码分析的第二部分 - 在线迁移(热迁移/动态迁移)源码分析;和之前的静态迁移(离线迁移)源码分析一样,也用两篇博文详细阐述liberty中热迁移的过程,两篇博文的内容划分如下:
- 第一篇:分析
nova-api
,nova-conductor
的处理过程 - 第二篇:分析
nova-compute
的处理过程
下面来看第一篇,在线迁移过程中nova-api
,nova-conductor
的处理过程:
发起在线迁移
用户可以通过 nova live-migration
发起在线迁移操作,如:
#nova --debug live-migration 57fe59d1-2566-42c1-8b17-b2a1e50c889e
可以通过
nova help live-migration
帮助命令查看使用规则
--debug
选项用来打印客户端调试日志:
POST http://10.240.xxx.xxx:8774/v2.1/25520b29dce346d38bc4b055c5ffbfcb/servers/57fe59d1-2566-42c1-8b17-b2a1e50c889e/action -H "User-Agent: python-novaclient" -H "Content-Type: application/json" -H "Accept: application/json" -H "X-OpenStack-Nova-API-Version: 2.6" -H "X-Auth-Token: {SHA1}6b48595f60d527e2c55a182c65c32c6f9cc76e67" -d '{
"os-migrateLive": {
"disk_over_commit": false, "block_migration": false, "host": null}}'
从上面的日志以及nova-api
启动时建立的路由映射,我们很容易的知道消息的入口是:nova/api/openstack/compute/migrate_server.py/MigrateServerController._migrate_live
,下面一起来看看具体的处理过程:
nova-api
处理阶段
#这里省略装饰器定义(知道:装饰器在函数之前执行,并且各个装饰器的执行顺序与#声明顺序相反即可)
def _migrate_live(self, req, id, body):
"""Permit admins to (live) migrate a server to a new
host.
参数如下:
req Request对象,包含请求的详细信息
id 待迁移的云主机的uuid 57fe59d1-2566-42c1-8b17-b2a1e50c889e
body 请求体,包含本次请求的参数 {"os-migrateLive":
{"disk_over_commit": false, "block_migration": false,
"host": null}}
"""
#得到请求上下文
context = req.environ["nova.context"]
"""根据CONF.policy_file=`/etc/nova/policy.json`文件及
CONF.policy_dirs目录下策略文件中定义的策略认证该action在context上
下文中是否合法,适用的规则是:
"os_compute_api:os-migrate-server:migrate_live":
"rule:admin_api",如果没有定义相应的规则,则尝试执行默认规则
(CONF.policy_default_rule, 适用的规则
是:"default":"rule:admin_or_owner"),认证失败,抛异常
"""
authorize(context, action='migrate_live')
#根据请求体body获取配置参数
block_migration = body["os-migrateLive"]["block_migration"]
disk_over_commit = body["os-migrateLive"]["disk_over_commit"]
host = body["os-migrateLive"]["host"]