一、虚拟机迁移分析

openstack虚拟机迁移分为冷迁移和热迁移两种方式。

1.1冷迁移：

冷迁移(cold migration)，也叫静态迁移。关闭电源的虚拟机进行迁移。通过冷迁移，可以选择将关联的磁盘从一个数据存储移动到另一个数据存储。

好处：虚拟机不需要位于共享存储器上，数据丢失率小。

缺点：需要关闭电源，业务中断。

1.2热迁移：

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

好处：软件和硬件系统的维护升级，不会影响用户的关键服务，提高了服务的高可用性和 用户的满意度。

缺点：过程不可中断，操作复杂。

1.3虚拟机迁移的场景：

场景 1：物理机器硬件系统的维护，故障修复和升级(upgrade)，但运行在这台物理机器上的虚拟机不能关机，因为用户重要的服务跑在上面。

场景 2：物理机器软件系统升级，打补丁(patch)，为了不影响上面跑的虚拟机，在升级和打补丁之前，需要把虚拟机迁移到别的物理机器上。

场景 3：一个物理机器上的负载太重，需要减少一些虚拟机来释放资源。

场景 4：跨域环境下，有的域里有的物理机上的虚拟机太多，有的域里物理机上虚拟机太少，做一下资源平衡。

1.4虚拟机迁移中数据处理

虚拟机的迁移，就是数据的转移，如果计算节点之间没有共享存储，所以要转移的数据包括两部分：

1、静态数据：存储在本地的虚拟机的镜像文件，包括后端镜像(libvirt Base)和虚拟机单独的增量镜像文件(libvirt instance disks)。

2、动态数据：内存里虚拟机的运行时数据，内存里的数据是动态变化的数据，虚拟机里运行的负载的大小直接影响迁移的时间长短。

1.5虚拟机迁移中存储

共享存储与非共享存储

虚拟机的数据存在共享磁盘上(Shared storage-based live migration)，迁移只需要完成内存数据的迁移。

虚拟机的数据存在本地磁盘(block migration)，需要对镜像文件和内存数据同时迁移。

注意：本文使用的系统是ubuntu18.04，OpenStack版本是Pike。其他系统略有出入

二、冷迁移

冷迁移实现方法有多种，例如有快照来迁移实例、实例文件迁移。以文件迁移为例，完成冷迁移。

2.1虚拟机文件冷迁移步骤：

1、关闭虚拟机

2、找到虚拟机位于/var/lib/nova/instances下文件

3、将虚拟机的文件全部copy到目标主机的相同位置下

4、修改用户组

5、更新数据库中host,node字段为目标主机的名字

6、重启目标主机的nova-compute服务

2.2操作记录

显示运行的虚机

关闭虚机

将文件copy到目标主机的对应位置下

修改权限

修改数据库中的字段

update instances set host=\’compute15\’, node=\’compute15\’ where uuid=\’3483d9f1-4015-48d9-9837-b67ca82dd54d\’;

查询虚机所在的主机

 启动虚机

三、热迁移

热迁移是在不停机的情况下完成迁移，步骤比起冷迁移要复杂。

3.1热迁移步骤：

1、迁移前的条件检查

2、迁移前的预处理

3、迁移过程

4、迁移后的处理

3.1.1迁移前的条件检查

动态迁移要成功执行，一些条件必须满足，所以在执行迁移前必须做一些条件检查。

1、权限检查，执行迁移的用户是否有足够的权限执行动态迁移。

2、参数检查，传递给 API 的参数是否足够和正确，如是否指定了 block-migrate 参数。

3、检查目标物理主机是否存在。

4、检查被迁移的虚拟机是否是 running 状态。

5、检查源和目的物理主机上的 nova-compute service 是否正常运行。

6、检查目的物理主机和源物理主机是否是同一台机器。

7、检查目的物理主机是否有足够的内存(memory)。

8、检查目的和源物理主机器 hypervisor 和 hypervisor 的版本是否相同。

3.1.2迁移前的预处理

在真正执行迁移前，做一些准备工作

1、在目的物理主机上获得和准备虚拟机挂载的块设备(volume)。

2、在目的物理主机上设置虚拟机的网络(networks)。

3、目的物理主机上设置虚拟机的防火墙(fireware)。

3.1.3迁移过程

条件满足并且做完了预处理工作后，就可以执行动态迁移了。主要步骤如下：

1、调用 libvirt python 接口 migrateToURI，来把源主机迁移到目的主机。

2、以一定的时间间隔（0.5）循环调用 wait_for_live_migration 方法，来检测虚拟机迁移 的状态，一直到虚拟机成功迁移为止。

3.1.4迁移后的处理

当虚拟机迁移完成后，要做一些善后工作。

1、在源物理主机上 detach volume。

2、在源物理主机上释放 security group ingress rule。

3、在目的物理主机上更新数据库里虚拟机的状态。

4、在源物理主机上删除虚拟机。

上面四步正常完成后，虚拟机就成功的从源物理主机成功地迁移到了目的物理主机了。

3.2热迁移配置：

热迁移需要libvirt远程登录和传输，所以开启libvirt的TCP连接方式

virsh -c qemu+tcp://172.171.8.14/system

例如：qemu+tcp://172.16.0.15/system，服务端只需要配置。

修改/etc/libvirt/libvirtd.conf:

listen_tls = 0　　　　　　　　　

listen_tcp = 1　　　　　　　　　  

tcp_port = "16509"　　　　　　

listen_addr = "0.0.0.0"

auth_tcp = "none"

 修改libvirtd的配置文件/etc/default/libvirtd:

# Start libvirtd to handle qemu/kvm:

start_libvirtd="yes"

# options passed to libvirtd, add "-l" to listen on tcp

libvirtd_opts="-d -l --config /etc/libvirt/libvirtd.conf"

以上修改后，执行

service libvirt-bin restart

netstat -anpt | grep libvirt

可以看到libvirtd监听在TCP 16509端口。

配置nova.conf

计算节点的/etc/nova/nova.conf文件中添加如下的内容，使得compute服务支持热迁移。

live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

重启nova-compute

service nova-compute restart

修改用户组

查看目标主机的用户组信息

id nova

 修改所有计算节点为相同的用户组id。

usermod -u *** nova

usermod -u *** libvirt-qemu

groupmod -g *** nova

groupmod -g *** kvm

openstack迁移命令

查看所有实例

nova list

查看需要迁移虚拟机实例

nova show [实例id]

查看可用的计算节点

nova-manage service list

查看目标节点资源

nova-manage service describe_resource computer1

开始迁移，正常无任何回显

nova live-migration  [实例id]  [计算节点] 

3.3操作记录

查看虚拟机

查看虚拟机所在计算节点

迁移

查看迁移后的虚拟机所在节点

在迁移过程中，dashboard中会出现正在迁移的任务

3.4 大型镜像测试

OpenLab平台镜像迁移

创建虚拟机，镜像是ubuntu，1.8G

迁移之前ubuntu所在的主机为compute14

迁移中 

迁移之后ubuntu所在的主机为compute15

运行测试

创建虚拟机ubuntu_two，所在主机为compute14

迁移之前的界面

迁移过程

迁移之后的虚拟机所在的主机为compute15

迁移过程很快，2min左右，迁移之后界面仍然是之前的界面