openstack热迁移操纵及常见问题

热迁移操作手册

一、操作方法

1.1 底层操作

1.1.1 查找需要迁移虚机所在的宿主机

登录控制节点01

# 刷新环境变量
source /root/keystonerc_admin

#通过ip查找需要迁移虚机的uuid
 nova list --all | grep ${vm_ip}
 
#通过uuid查找需要迁移虚机所在的宿主机
nova show ${vm_uuid} | grep hypervisor_hostname

1.1.2 迁移虚拟机

#热迁移命令
#<service> 是需要迁移虚机的uuid
#[<host>] 是需要迁移到宿主机的名称
nova live-migration <server> [<host>]

二、注意事项

2.1 目标节点需要资源充足

2.1.1 底层操作

• 控制节点执行以下命令，查看迁移目标节点的资源是否满足

#查看目标节点的资源剩余量
#[<host>] 是需要迁移到宿主机的名称,
openstack hypervisor list --long | grep [<host>]

# 登录目标节点查看资源超分比
[root@com03 ~]# grep  allocation_ratio /etc/nova/compute.conf
cpu_allocation_ratio = 4.0
ram_allocation_ratio = 1.0

#判断资源是否满足
cpu剩余量= $[vCPUs]*$[cpu_allocation_ratio] - $[vCPU Used]
men剩余量= $[Memory MB]*$[ram_allocation_ratio] - $[Memory MB Used]

2.2 selinux限制

premissive–>disabled不可以进行热迁移

登录源节点和目标节点查看

[root@test ~]# getenforce 
Disabled

2.3 源与目标计算节点必须同属于一个AZ集合下

• 如果不是一个AZ：

  • 为源AZ添加允许迁移到其他AZ的参数，在管理节点执行命令

  #添加
  openstack aggregate set –-property allow_migrate_to_other_az=true AZ名称
  #查看添加元数据后AZ的状态信息
  openstack aggregate show AZ名称
  

2.4 目标计算节点必须包含源计算节点cpu的flag集合

1. 登录虚拟机源计算节点，用以下命令获取计算节点CPU信息

virsh capabilities > /tmp/capabilities.txt
virsh cpu-baseline /tmp/capabilities.txt > /tmp/cpu.xml

2. 把生成的CPU信息文件拷贝到迁移的目的主机

# destination_host_IP为迁移的目的主机的管理IP地址
scp /tmp/cpu.xml root@destination_host_IP:/tmp/cpu.xml

3. 目标宿主机执行以下命令判断CPU信息是否兼容

virsh cpu-compare /tmp/cpu.xml

输出信息为：Host CPU is a superset of CPU described in cpu.xml

则表明cpu兼容，可以进行热迁移

三、常见问题

3.1 迁移失败问题排查思路：

• 迁移虚机是否满足注意事项

• 用虚机的uuid查看原计算节及目标节点点/var/log/nova/nova-compute.log是否有报错信息

• 用nova instance-action-list命令拿到迁移Request_ID，用此id在三个控制节点及相关计算节点查找相关报错

3.2 迁移一直卡在migrating

3.2.1 判断虚机是否迁移成功

#查看迁移状态，如果有输出迁移速率则还在迁移中，反正按下一步查询
#${instance_name}可用nova show ${vm_uuid} | grep instance_name命令查看

virsh domjobinfo ${instance_name}

#目的节点查询不到相关虚拟机，且/var/log/nova/nova-compute.log日志无报错，虚机还源节点则没有迁移成功
virsh list --all | grep  ${instance_name}

3.2.2 没有迁移成功

目标节点查询不到虚机信息且无日志无报错说明没有迁移，虚机查看源节点/var/log/nova/nova-compute.log日志查看相关报错，需要重启迁移需要重置虚机状态

#重置虚机状态
nova reset-state bb77ff04-5d8d-488b-b252-a957996ca49e --active

3.2.3 正在迁移中

问题原因：

• 虚拟机存在频繁的数据读写操作，导致虚拟机迁移的速度追不上数据读写的速度，每次迁移完内存数据又产生
  大量新数据，导致虚拟机一直处于迁移中的状态
  现象：

#虚拟机在迁移的时候可以在源宿主机上执行下面命令查看对应虚拟机的迁移进度
watch -n 1 virsh domjobinfo ${instance_name}

#如果发现迁移速度一直追不上写入的速度（如果Data remaining字段的值一直降到0后又出现新的迁移数据，但
数据量不大，只要几十M的话）那就是迁移的速度追不上数据读写的速度，建议冷迁移。

方法：

• 那就是迁移的速度追不上数据读写的速度，等待迁移超时，建议冷迁移。

• 可以考虑在源计算节点上执行virsh suspend id暂停下虚拟机，这样就可以顺利迁移过去了。但不要一上来就直接suspend，要观察下确认是真的迁移不过去再暂停。（可能会影响业务，慎用）

3.2.4 迁移完成

现象：

• 源节点virsh list --all | grep ${instance_name}找不到虚机

• 目标节点virsh list --all | grep ${instance_name}可以看到虚机

• 等待一段时间后底层nova list --all | grep ${vm_ip}还是处于迁移中

解决：

1. 重置虚机状态

source /root/keystonerc_admin
nova reset-state <instance_uuid> --active

2. 查看宿主机是否正确

# 查看OS-EXT-SRV-ATTR:host是否是目前的宿主机
nova show <instance_uuid>

3. 如果不正确则需要修改数据库

#登录基础云任意一台控制节点，访问mysql数据，修改nova.instances库的host和node字段值为新宿主机主机名，<new_compute_node>替换为新宿主机主机名
select * from nova.instances where uuid='<instance_uuid>'\G
update nova.instances set node='<new_compute_node>' where uuid='<instance_uuid>';
update nova.instances set host='<new_compute_node>' where uuid='<instance_uuid>';

#通过虚拟机ip（<instance_ip>）查看虚拟机ip的port id，以下用<port_id>表示
neutron port-list |grep <instance_ip>

#登录基础云任意一台控制节点，访问mysql数据库，修改neutron.ml2_port_bindings库的host字段值为新宿主机主机名，<new_compute_node>替换为新宿主机主机名
select * from neutron.ml2_port_bindings where port_id='<port_id>'\G
update neutron.ml2_port_bindings set host='<new_compute_node>' where port_id='<port_id>';

3.3 宿主机报Connection refused

报错unable to connect to server at 'com03:16509': Connection refused

排查：

• 到迁移的目标节点查看端口是否启动

  [root@com04 ~]# cat /etc/hosts | grep com03
  192.168.1.4 com03
  
  [root@com03 ~]# netstat -naput | grep 16509
  tcp        0      0 192.168.1.4:16509      0.0.0.0:*               LISTEN      405201/libvirtd     
  

  发现端口对应的ip于宿主机/etc/hosts不符合，导致telnet端口不通。

解决：

更改宿主机的/etc/hosts改成libvirtd(netstat -naput | grep libvirtd )服务端口对应的ip

3.4 报rpc_response连接rabbitmq响应动作超时

现象：查看源计算节点/var/log/compute.log日志有如下报错：Post live migration at destination XXX failed:MessagingTimeout: Timed out waiting for a reply to message ID XXX

解决：
更改源计算节点/etc/nova/compute.conf修改平台定义的默认rpc_response_timeout时间，增加超时时间为600s