openstack 公开版 热迁移和冷迁移

admin

迁移类型：

*非在线迁移 (有时也称之为‘迁移’)。也就是在迁移到另外的计算节点时的这段时间虚拟机实例是处于宕机状态的。在此情况下，实例需要重启才能工作。

*在线迁移 (或 '真正的在线迁移')。实例几乎没有宕机时间。用于当实例需要在迁移时保持运行。在线迁移有下面几种类型：

* 基于共享存储的在线迁移。所有的Hypervisor都可以访问共享存储。* 块在线迁移。无须共享存储。但诸如CD-ROM之类的只读设备是无法实现的。* 基于卷的在线迁移。实例都是基于卷的而不是临时的磁盘，无须共享存储，也支持迁移(目前仅支持基于libvirt的hypervisor)。什么是热迁移

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

openstack热迁移

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

回到顶部

3 ]3 T7 P' _# @4 k# R8 z7 U% y% `迁移步骤

• 迁移前的条件检查
  动态迁移要成功执行，一些条件必须满足，所以在执行迁移前必须做一些条件检查。
  • 权限检查，执行迁移的用户是否有足够的权限执行动态迁移。
  • 参数检查，传递给 API 的参数是否足够和正确，如是否指定了 block-migrate 参数。
  • 检查目标物理主机是否存在。
  • 检查被迁移的虚拟机是否是 running 状态。
  • 检查源和目的物理主机上的 nova-compute service 是否正常运行。
  • 检查目的物理主机和源物理主机是否是同一台机器。
  • 检查目的物理主机是否有足够的内存(memory)。
  • 检查目的和源物理主机器 hypervisor 和 hypervisor 的版本是否相同。
    
    ) y* B- Y' G2 g) {$ x3 \$ Q( b
• 迁移前的预处理
  

在真正执行迁移前，必须做一下热身，做一些准备工作。
* 在目的物理主机上获得和准备虚拟机挂载的块设备(volume)。

* 在目的物理主机上设置虚拟机的网络(networks)。* 目的物理主机上设置虚拟机的防火墙(fireware)。

• 迁移
  3 M& V: t4 ^. `条件满足并且做完了预处理工作后，就可以执行动态迁移了。主要步骤如下：
  • 调用 libvirt python 接口 migrateToURI，来把源主机迁移到目的主机。
    / z, V8 i) T" A9 B! hdom.migrateToURI(CONF.live_migration_uri % dest,logical_sum,None,CONF.live_migration_bandwidth)
    live_migration_uri：这个 URI 就是在 3.2.2 里介绍的 libvirtd 进程定义的。
    # D# F; |; y2 }- J. `( klive_migration_bandwidth：这个参数定义了迁移过程中所使用的最大的带宽。
  • 以一定的时间间隔（0.5）循环调用 wait_for_live_migration 方法，来检测虚拟机迁移 的状态，一直到虚拟机成功迁移为止。
    
• 迁移后的处理
  ! t7 a4 ?/ x8 a+ z当虚拟机迁移完成后，要做一些善后工作。
  • 在源物理主机上 detach volume。
  • 在源物理主机上释放 security group ingress rule。
  • 在目的物理主机上更新数据库里虚拟机的状态。
  • 在源物理主机上删除虚拟机。
    
    ' Z+ G; P( U: Q" J+ v
  
  5 [2 F; b* o% E* l3 R4 @9 _6 |

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

回到顶部

" l- V; p4 S' {4 [# j/ J6 SLive Migration 的实现

热迁移条件：

1.计算节点之间可以通过主机名互相访问
1 C3 b* P8 n! k& d6 A; m- W' k; u
2.计算节点和控制节点的nova uid和gid保持一致

3.vncserver_proxyclient_address和vncserver_listen 监听的是本地IP

4.必须有共享存储，实例存放在共享存储中，且每个计算节点都可以访问共享存储。否则只能使用块迁移

回到顶部

, s4 C. ?, e7 M$ \( G3 y, p( h% b配置

• 添加live_migration_flag
  
  

修改nova的配置文件，在[libvirt] 段下 添加如下字段

6 Q& u) a6 V$ M7 N* |

live_migration_flag="VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_PERSIST_DEST,VIR_MIGRATE_TUNNELLED"

, C/ D* j4 U0 M( X9 }, x& o

• 修改libvirt配置
  配置versh免密码连接，修改/etc/libvirt/libvirtd.conf
  
  8 v% }* }9 N7 E/ d7 C

添加如下配置

listen_tls = 0

listen_tcp = 1t

cp_port = "16509"

listen_addr = "172.16.201.8"   #根据自己的计算节点IP改写

7 G7 g& h5 {/ \8 y+ Y% O

auth_tcp = "none"

, C! B# w; x' U8 R$ m# Y/ Y! W7 W

修改/etc/sysconfig/libvirtd 添加如下参数

LIBVIRTD_CONFIG=/etc/libvirt/libvirtd.conf

LIBVIRTD_ARGS="--listen"

重启libvirt

systemctl restart libvirtd.service

查看监听端口：

[root@compute1 ~]# netstat -lnpt | grep libvirtdtcp        0      0 172.16.206.6:16509      0.0.0.0:*               LISTEN      9852/libvirtd

测试：

在compute1节点上：

virsh -c qemu+tcp://compute2/system在compute2节点上virsh -c qemu+tcp://compute1/system如果能无密码连接上去，表示配置没问题

回到顶部

动态迁移

• 查看所有实例
  + q* Q  }2 j8 Z8 x

nova list

• 查看需要迁移虚拟机实例
  

nova show f3d749ba-98e1-4624-9782-6da729ad164c

• 查看可用的计算节点
  : D9 s9 v9 {1 E  U5 mnova-manage service list
• 查看目标节点资源
  nova-manage service describe_resource computer1
• 开始迁移，正常无任何回显
  
  

nova live-migration 8da00f69-05f6-4425-9a8a-df56b79a474f computer1

• 也可以通过dashboard 节点迁移
  2 B9 \; E* p2 V$ p用节点迁移需要使用admin管理员用户执
  : E) N) R3 j/ I! v5 k+ d$ U

冷迁移配置

冷迁移需要启动nova账户，并配置ssh 免密码认证

usermod -s /bin/bash novasu - novassh-keygen

enter
enter
: X( @2 ^2 c& {7 ]enter#生成密钥cat .ssh/id_rsa.pub >> .ssh/authorized_keys

' n! Y4 F4 Z& b9 j% ?

将密钥复制到所有计算节点的/var/lib/nova/.ssh下，并设置权限为nova用户

编辑/etc/nova/nova.conf的配置文件，修改下面参数

allow_resize_to_same_host=True scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,ServerGroupAntiAffinityFilter,ServerGroupAffinityFilter

在计算节点重启nova服务

systemctl restart openstack-nova-compute.service

在controller节点重启nova 相关服务

systemctl restart openstack-nova-api.service openstack-nova-scheduler.service

admin

配置方案
1.修改Nova.conf文件
添加：
image_cache_manager_interval=0
7 O0 ?+ {. j+ J  Hlive_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_UNSAFE
1 l) x0 Y9 M  U7 P9 b$ a修改：
vncserver_listen=0.0.0.0
2.参与的计算节点机器名字都能ping通。
& d2 i: R  |! v8 w" T# h3.修改计算节点上 /etc/libvirt/libvirtd.conf:
6 r8 G# w! P& A, k3 e# o
before : #listen_tls = 0
! e$ P( W( `& N( s% zafter : listen_tls = 0

before : #listen_tcp = 1
after : listen_tcp = 1

" d% m0 H5 v2 |! Cadd: auth_tcp = "none"

4.修改 /etc/sysconfig/libvirtd:
9 h, U/ N1 M  R, ]: l7 Abefore :# LIBVIRTD_ARGS="--listen"
after :LIBVIRTD_ARGS="–listen"
5.在源计算节点上修改要迁移虚机的/var/run/libvirt/qemu/instance–xxx.xml文件
4 a5 Y1 ]" ^* l* g8 g( ?& ^$ I( p5 x删除migrate-qemu-fd这一行，将vnc参数修改成0.0.0.0
  p! Q* b8 Q, o! M' H8 \6.重启计算节点上nova
0 Z" c7 L0 l% v% I. b6 ~7备注：
1.由于云机之前没有配置在线迁移，在迁移虚机之前，需要重启虚机。
2..因为计算节点上libvirtd的配置中增加了auth_tcp="none"，算是一个安全漏洞，需要寻找更安全的办法，或者在迁移完成之后，注释掉这行，重启libvirt
3 已经编写了一个辅助程序自动做迁移
0 w1 ?4 }$ N: r1 _$ |+ U
遇到的问题和解决办法
( {* w+ _9 X6 Y6 h! I) V6 `
" A8 O- I2 x$ D! r2 q1.虚机的disk 的cache mode为writethrough，迁移的时候报错
% W& j) {6 O. }. kopenstack认为在centos上磁盘cache mod为writethrough时，迁移是不安全的。
解决的办法  ：在nova.conf live_migration_flag参数后面增加VIR_MIGRATE_UNSAFE，官方在线迁移配置文件里没有这个参数。
2.qemu1.4的一个bug导致迁移失败
迁移失败，在目的节点上/var/log/libvrit/qemu/instances--xxxx.log里：
# m+ }2 Y+ Q1 h& a" l/ Tchar device redirected to /dev/pts/1 (label charserial1)
- X  _& }8 G4 P& t5 l( hqemu: warning: error while loading state section id 2
load of migration failed
解决办法：
1.在源计算节点上修改要迁移虚机的/var/run/libvirt/qemu/instance–xxx.xml文中删除migrate-qemu-fd这一行
+ b; Z" ~$ `+ Y7 \& j  {2.重启源计算节点上的libvirtd
3.然后再执行nova live-migration命令

这个操作已经编写了一个程序自动执行。
3.vncserver的问题，需要重启虚拟机才可以迁移。
5 o4 T2 I/ L3 {5 p4 T. Y 由于之前Nova.conf中vncserver_listen=计算机节点的ip，所以在虚拟机Kvm进程中参数中vnc=计算节点的ip，迁移的时候报错，在目的节点绑定不了源节点的IP,所以需要修改Libvirt.xml配置文件，重启虚机，然后才能进行迁移。
+ `1 y+ V/ U$ Y, G, G/ m解决办法：

1.在源计算节点上/var/run/libvirt/qemu/instance–xxx.xml文中将vnc的参数修改成0.0.0.0
2 F; p. ^, {4 o+ u% L
4 F) n8 l) V" e' @; l2.重启源计算节点libvirtd
6 X) W9 P  t! J" Z8 O0 X
3.然后再执行nova live-migration命令

这个操作已经编写了程序来自动完成

4.迁移完成后console.log,disk属主变成了root/root
迁移完成后，发现虚机的console.log和disk文件属主由qemu.qumu变成了root.root，这个估计是openstack迁移程序的问题，这个问题目前没有影响虚机。
解决办法:
6 @3 b( A  }. \/ i7 `$ l修改文件属主，这个操作已经编写了程序来自动完成
& n  W% N* m3 I1 d5.源节点和目的节点cpu不兼容问题
2 M7 o8 F3 E1 A6 U5 q) y  }1 N迁移失败，在/var/log/nova/compute的日志：
5 W, |  I# d* `$ N5 k: }# F "InvalidCPUInfo: Unacceptable CPU info: CPU doesn't have compatibility.\n\n0\n\nRefer to http://libvirt.org/html/libvirt-libvirt.html#virCPUCompareResult\n"]
解决办法：
* n: r% z2 {( H/ F4 g, S目前还没有解决办法
# a2 v& e7 g1 o, y& _0 u6.目的节点内存为负，
迁移失败，从控制节点的api.log上输出的错误是目的节点内存为-3400，不能满足迁移的需要。
: b8 q" t2 d3 a( e' h/ E
6 D8 j$ B/ l5 X- ?解决办法：
$ i9 H1 s, R' W! k2 v
) t# N3 Q* P; l0 O用nova命令指定在该计算节点上创建虚机，能够成功。估计是迁移时候的调度算法和创建虚机时的调度算法不一致。

7.错误日志，在2.4上api.log
4 {( c) B8 n' G- W迁移时候一般看的日志有：
1.目的节点上的/var/log/libvirt/qemu/instances–xxx.log
2.目的节点上的/var/log/nova/compute.log
' O' s1 c* O, o" Q& C$ {3.源节点上的/var/log/nova/compute.log
" \+ k1 O8 a% r4 B& v有时候迁移失败，命令行执行后报错：
ERROR: Live migration of instance bd785968-72f6-4f70-a066-b22b63821c3b to host compute-13 failed (HTTP 400) (Request-ID: req-180d27b5-9dc7-484f-9d9a-f34cccd6daa2)
: {. o" N; g( O- l" q+ I- |但在上述的三个日志文件中都看不到任何的错误信息。
2 S9 T4 ~! [8 }# F
解决办法：
% M% ^+ V+ H- g1 N在控制节点或者是在操作迁移命令的节点上/var/log/nova/api.log有错误信息

走的弯路
2 l: o$ K" E  t7 m. V
1 x2 l$ S# j% z1.尝试不用修改nova.conf里的vncserver_listen参数为0.0.0.0，
将/var/run/log/libvirt/qemu/instances--xxx.log里的vnc改成目的节点的ip，重启libvritd，然后进行迁移，可以成功，但如果迁移失败，当需要重新虚机的时候，虚机启动失败，在/var/log/libvrit/qemu/instances-xx.log的错误是
4 O9 ^/ M( K; EFailed to start VNC server on `172.18.2.15:0': Failed to bind socket: Cannot assign requested address
5 c/ S" U5 E4 b1 W" [9 v而/mnt/instances/instance--xxx/libvirt.xml里没有修改成目的节点的Ip。不知道这个参数被保存到了哪里
( U1 Z3 G: O8 ^$ C, N" b9 z2.vnc 端口问题
5 ?4 h. Y4 i9 E/ W在一次迁移失败后，在目的节点/var/log/libvirt/qemu/instance--xxx.log里的错误是：
2013-11-05 05:42:39.401+0000: shutting down
$ |7 ]1 \9 p7 H) ?qemu: terminating on signal 15 from pid 10271，
0 n( l: n. b# A9 L5 R. V6 D
1 j1 y7 P& U% ~: e3 P+ q猜想是由于虚机在源节点上的vnc监听端口在目的节点上被占用，所以导致启动不了。后来在其他机器上做了测试发现，在迁移到目的节点后vnc的端口自己会调整。

admin

nova migrate  4618373d-164f-4f5e-96b4-e59f4f2c3d86   冷迁移命令
$ T$ N& F7 t: ]4 d6 j4 x& F' X) topenstack server migrate  4618373d-164f-4f5e-96b4-e59f4f2c3d86  冷迁移命令  不能指定物理机