OpenStack实现热迁移(live-migration)及经验总结

OpenStack实现热迁移(live-migration)
1.什么是热迁移？
2.live migration和block migration这两种类型迁移有什么特点？
3.迁移过程中如果硬件资源不匹配，可能会遇到什么问题？

热迁移

热迁移（Live Migration，又叫动态迁移、实时迁移），即虚拟机保存/恢复(Save/Restore)：将整个虚拟机的运行状态完整保存下来，同时可以快速的恢复到原有硬件平台甚至是不同硬件平台上。恢复以后，虚拟机仍旧平滑运行，用户不会察觉到任何差异。

openstack热迁移

OpenStack有两种在线迁移类型：live migration和block migration。Livemigration需要实例保存在NFS共享存储中，这种迁移主要是实例的内存状态的迁移，速度应该会很快。Block migration除了实例内存状态要迁移外，还得迁移磁盘文件，速度会慢些，但是它不要求实例存储在共享文件系统中。
* NFS允许一个系统在网络上与他人共享目录和文件。通过使用NFS，用户和程序可以像访问本地文件一样访问远端系统上的文件。


Live Migration 的实现

1.机器：
jovi-controller 是控制节点 192.168.3.10
jovi-compute1 是计算节点 192.168.3.12
jovi-compute3 是计算节点 192.168.3.14
实验阶段，为了避免不必要的麻烦，请用命令service ufw stop关闭各个节点的防火墙，同时修改/etc/hosts文件，确定节点之间能互相ping通主机名。利用id nova命令查看下控制节点nova的uid和gid，并记录，在两个计算节点同样利用id nova查看uid和gid是否和控制节点保持一致，如果不一致则利用usermod -u 控制节点的uid nova和gropumod -g 控制节点的gid nova 两条命令进行修改,同时在所有计算节点运行如下命令，保证所有nova相关文件使用新的uid和gid
[root@vmcom1-mn ~]#service nova-api stop
[root@vmcom1-mn ~]#service libvirt-bin stop
[root@vmcom1-mn ~]#find / -uid 106 -exec chown nova {} \; # note the 106 here is the old nova uid before the change
[root@vmcom1-mn ~]# find / -gid 107 -exec chgrp nova {} \; #note the 107 here is the old nova uid before the change
[root@vmcom1-mn ~]#service nova-api restart
[root@vmcom1-mn ~]#service libvirt-bin restart

2.修改各个节点的nova.conf
vncserver_proxyclient_address=本机ip
vncserver_listen=0.0.0.0

3.控制节点，配置nfs

apt-get install nfs-kernel-server portmap
在/etc/exports中加入/var/lib/nova/instances *(rw,sync,fsid=0,no_root_squash)
重新启动nfs服务,portmap服务

4.计算节点，配置nfs和挂载

apt-get install nfs-common portmap
chmod o+x /var/lib/nova/instances,确保节点有执行和查找目录的权限
在计算节点的/etc/fstab的目录中加入
控制节点ip:/var/lib/nova/instances /var/lib/nova/instances nfs defaults 0 0
挂载目录，执行
mount -a -v
df -k 查看已挂在目录，可以在最后看到远程控制节点的目录已被挂在

5.修改计算节点的相关的四个配置文件，可以手工如下修改

附修改脚本：
sed -i '/vncserver_proxyclient_address/d' /etc/nova/nova.conf
sed -i '/vncserver_listen/d' /etc/nova/nova.conf
sed -i '$a\vncserver_listen=0.0.0.0' /etc/nova/nova.conf
sed -i 's/#listen_tls = 0/listen_tls = 0/g' /etc/libvirt/libvirtd.conf
sed -i 's/#listen_tcp = 1/listen_tcp = 1/g' /etc/libvirt/libvirtd.conf
sed -i '$a\auth_tcp="none"' /etc/libvirt/libvirtd.conf
sed -i 's/env libvirtd_opts="-d "/env libvirtd_opts="-d -l"/g' /etc/init/libvirt-bin.conf
sed -i 's/libvirtd_opts=" -d"/libvirtd_opts=" -d -l"/g' /etc/default/libvirt-bin
sed -i 's/#vnc_listen = “0.0.0.0″/vnc_listen = “0.0.0.0″/g' /etc/libvirt/qemu.conf
sed -i 's/#user = "root"/user = "root"/g' /etc/libvirt/qemu.conf
sed -i 's/#group = "root"/group = "root"/g' /etc/libvirt/qemu.conf


6.重新启动libvirt-bin

service libvirt-bin restart
确定进程已启动。
ps -ef | grep libvirt
确定有libvirtd -d -l进程存在
root 5277 1 004:06 ? 00:00:01/usr/sbin/libvirtd -d -l

7.重新启动nova-compute服务，portmap服务

service nova-compute restart
service portmap restart

8.测试

root@jovi-controller:~# nova list 查看实例
root@jovi-controller:~# nova show 11fd9622-a948-4cdb-94d0-d8f2558cf179 查看需要迁移的实例
root@jovi-controller:~# nova-manage service list查看可用的计算节点
root@jovi-controller:~# nova-manage service describe_resource compute-node2查看目标节点资源
root@jovi-controller:~#nova live-migration 11fd9622-a948-4cdb-94d0-d8f2558cf179 jovi-compute3 迁移成功，应该没有输出。

相关问题的总结：

部署过程中曾遇到两个导致无法迁移成功的错误，一个是在日志文件中发现cpu info incapable，另外一个问题是在日志文件中发现failed to connect remote host uri，经过与最后实验成功的环境相对照，发现实际上导致这两个问题的最终原因是计算节点的计算资源不匹配，例如之前失败的情况是compute1节点 cpu 4核心，8g内存，compute3节点 cpu 2核心，内存4g，所以提示出现上述错误。

本质是因为在openstack源码中，有一段针对热迁移时节点计算资源检测的函数，该函数的作用检测迁移的源节点和目的节点的计算资源是否匹配，从而判断能否承载实例的运行。

因此后来将两个计算节点都调整为双核，4g内存，按之前方案配置后，即可成功实现迁移。

另外网上的部署方案都提到了要修改nova.conf中vncserver_proxyclient_address=127.0.0.1，笔者经过测试，这这种方法只适用于单网卡的计算节点，多网卡情况下应该注意填写的是与控制节点以及其他计算节点互联网口的ip，这样dashboard中的vnc才可以成功运行，否则会提示faild to connect to server错误。

学习了，，，部署成功之后测试测试