Openstack VM live migration can have 3 categories:

-Block live migration without shared storage

-Shared storage based live migration

-Volume backed VM live migration

Block live migration

Block live migration does not require shared storage among nova-compute nodes, it uses network(TCP) to copy VM disk from source host to destination host, thus it takes longer time to complete than shared storage based live migration. Also during migration, host performance will be degraded in network and CPU points of view.

To enable block live migration, we need to change libvirtd and nova.conf configurations on every nova-compute hosts:

->Edit /etc/libvirt/libvirtd.conf

listen_tls = 0
listen_tcp = 1
auth_tcp = "none"

->Edit /etc/sysconfig/libvirtd

LIBVIRTD_ARGS="–listen"

->Restart libvirtd

service libvirtd restart

->Edit /etc/nova/nova.conf, add following line:

live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

>Restart nova-compute service

service openstack-nova-compute restart

->Check running VMs

nova list
+--------------------------------------+-------------------+--------+---------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+--------+---------------------+
| 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | ACTIVE | ncep-net=10.20.20.3 |
+--------------------------------------+-------------------+--------+---------------------+

->Check which host the VM in running on

nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T08:47:13Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-1 |

->Check all available hosts

nova host-list
+--------------+-------------+----------+
| host_name | service | zone |
+--------------+-------------+----------+
compute-1 | compute | nova |
compute-2 | compute | nova |

>Let's migrate the vm to host compute-2

nova live-migration  --block-migrate vm-live-migration compute-2

>Later when we check vm status again, we cloud see the host changes to compute-2

nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T09:45:33Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-2 |

>We can just do a migration without specifying destination host, nova-scheduler will choose a free host for you

nova live-migration  --block-migrate vm-live-migration

Shared storage based live migration

This example we use GlusterFS as shared storage for nova-compute nodes. Since VM disk is stored on shared storage, hence live migration much much more faster than block live migration.

1.Setup GlusterFS cluster for nova-compute nodes

->Prepare 4 nodes, each node has an extra disk other than OS disk, dedicated for GlusterFS cluster

Node 1: 10.68.124.18 /dev/sdb 1TB
Node 2: 10.68.124.19 /dev/sdb 1TB
Node 3: 10.68.124.20 /dev/sdb 1TB
Node 4: 10.68.124.21 /dev/sdb 1TB

->Configure Node 1-4

yum install -y xfsprogs.x86_64
mkfs.xfs -f -i size=512 /dev/sdb
mkdir /brick1
echo "/dev/sdb /brick1 xfs defaults 1 2" >> /etc/fstab 1014 cat /etc/fstab 
mount -a && mount
mkdir /brick1/sdb
yum install glusterfs-fuse glusterfs-server
/etc/init.d/glusterd start
chkconfig glusterd on

->On Node-1, add peers

gluster peer probe 10.68.125.19
gluster peer probe 10.68.125.20
gluster peer probe 10.68.125.21

->On node-1, create a volume for nova-compute

gluster volume create nova-gluster-vol replica 2 10.68.125.18:/brick1/sdb 10.68.125.19:/brick1/sdb 10.68.125.20:/brick1/sdb 10.68.125.21:/brick1/sdb
gluster volume start nova-gluster-vol

->We can check the volume information

gluster volume info
Volume Name: nova-gluster-vol
Type: Distributed-Replicate
Status: Started
Number of Bricks: 2 x 2 = 4
Transport-type: tcp
Bricks:
Brick1: 10.68.125.18:/brick1/sdb
Brick2: 10.68.125.19:/brick1/sdb
Brick3: 10.68.125.20:/brick1/sdb
Brick4: 10.68.125.21:/brick1/sdb

->On each nova-compute node, mount the GluserFS volume to /var/lib/nova/instances

yum install glusterfs-fuse
mount.glusterfs 10.68.125.18:/nova-gluster-vol /var/lib/nova/instances
echo "10.68.125.18:/nova-gluster-vol /var/lib/nova/instances glusterfs defaults 1 2" >> /etc/fstab
chown -R nova:nova  /var/lib/nova/instances

2.Configure libvirt and nova.conf on every nova-compute node

->Edit /etc/libvirt/libvirtd.conf

listen_tls = 0
listen_tcp = 1
auth_tcp = "none"

->Edit /etc/sysconfig/libvirtd

LIBVIRTD_ARGS="–listen"

->Restart libvirtd

service libvirtd restart

->Edit /etc/nova/nova.conf, add following line:

live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

3.Let's try live migration

->Check running VMs

nova list
+--------------------------------------+-------------------+--------+---------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+--------+---------------------+
| 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | ACTIVE | ncep-net=10.20.20.3 |
+--------------------------------------+-------------------+--------+---------------------+

->Check which host the VM in running on

nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T08:47:13Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-1 |

->Check all available hosts

nova host-list
+--------------+-------------+----------+
| host_name | service | zone |
+--------------+-------------+----------+
compute-1 | compute | nova |
compute-2 | compute | nova |

>Let's migrate the vm to host compute-2

nova live-migration  vm-live-migration compute-2

>Migration should be finished in seconds, let's check vm status again, we cloud see the host changes to compute-2

nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T09:45:33Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-2 |

>We can just do a migration without specifying destination host, nova-scheduler will choose a free host for us

nova live-migration vm-live-migration

3.Volume backed VM live migration

VMs booted from volume can be also easily and quickly migrated just like shared storage based live migration since both cases VM disks are on top of shared storages.

->Create a bootable volume from an existing image

cinder create  --image-id  --display-name bootable-vol-rhel6.3 5

->Launch a VM from the bootable volume

nova boot --image  --flavor m1.medium --block_device_mapping vda=:::0 vm-boot-from-vol

->Check which host the VM is running on

nova show vm-boot-from-vol 
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T10:29:09Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-1 |

->Do live migration

nova live-migration vm-boot-from-vol

->Check VM status again

nova show vm-boot-from-vol 
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T10:30:55Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-2 |

VM recovery from failed compute node

If shared storage used, or for VMs booted from volume, we can recovery them if their compute host is failed.

>Launch 1 normal VM and 1 volume backed VM, make they are all running on compute1 node. ( Use live migration if  they are not on compute-1)

nova show vm-live-migration 
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T10:36:35Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-1 |

nova show vm-boot-from-vol 
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | ACTIVE |
| updated | 2013-08-06T10:31:21Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-1 |

->Shutdown compute-1 node

[root@compute-1 ~]# shutdown now

->Check VM status

nova list
+--------------------------------------+-------------------+---------+---------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+---------+---------------------+
| 75ddb4f6-9831-4d90-b291-48e098e8f72f | vm-boot-from-vol | SHUTOFF | ncep-net=10.20.20.5 |
| 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | SHUTOFF | ncep-net=10.20.20.3 |
+--------------------------------------+-------------------+---------+---------------------+

Both VMs get into "SHUTOFF" status.

>Recovery them to compute-2 node

nova evacuate vm-boot-from-vol compute-2 --on-shared-storage 
nova evacuate vm-live-migration compute-2 --on-shared-storage

->Check VM status

nova show vm-boot-from-vol
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | SHUTOFF |
| updated | 2013-08-06T10:42:32Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-2 |

nova show vm-live-migration
+-------------------------------------+----------------------------------------------------------+
| Property | Value |
+-------------------------------------+----------------------------------------------------------+
| status | SHUTOFF |
| updated | 2013-08-06T10:42:51Z |
| OS-EXT-STS:task_state | None |
| OS-EXT-SRV-ATTR:host | compute-2 |

Both VMs are managed by compute-2 now

-> Reboot 2 VMs

nova reboot vm-boot-from-vol
nova reboot vm-live-migration

-> Check VMs list

nova list
+--------------------------------------+-------------------+--------+---------------------+
| ID | Name | Status | Networks |
+--------------------------------------+-------------------+--------+---------------------+
| 75ddb4f6-9831-4d90-b291-48e098e8f72f | vm-boot-from-vol | ACTIVE | ncep-net=10.20.20.5 |
| 5374577e-7417-4add-b23f-06de3b42c410 | vm-live-migration | ACTIVE | ncep-net=10.20.20.3 |
+--------------------------------------+-------------------+--------+---------------------+

Both VMs are back to ACTIVE.

Notes

Currently Openstack has no mechanism to detect host and VM failure and automatically to recover/migrate VM to health host, this reply on 3rd party means to do so

There's also an interesting project named openstack-neat, which is intended to provide an extension to OpenStack implementing dynamic consolidation of Virtual Machines (VMs) using live migration. The major objective of dynamic VM consolidation is to improve the utilization of physical resources and reduce energy consumption by re-allocating VMs using live migration according to their real-time resource demand and switching idle hosts to the sleep mode. This really like vSphere DRS function.

Project website: http://openstack-neat.org

来源:pete

Openstack虚拟机在线迁移(Live Migration)的更多相关文章

  1. 基于本地存储的kvm虚拟机在线迁移

    基于本地存储的kvm虚拟机在线迁移 kvm虚拟机迁移分为4种(1)热迁移基于共享存储(2)热迁移基于本地存储(3)冷迁移基于共享存储(4)冷迁移基于本地存储 这里介绍的是基于本地存储的热迁移 动态块迁 ...

  2. OpenStack虚拟机冷迁移与热迁移

    一.虚拟机迁移分析 openstacvk虚拟机迁移分为冷迁移和热迁移两种方式. 1.1冷迁移: 冷迁移(cold migration),也叫静态迁移.关闭电源的虚拟机进行迁移.通过冷迁移,可以选择将关 ...

  3. OpenStack 虚拟机热迁移流程图

    目录 文章目录 目录 源计算节点与目的计算节点之间的交互流程 Nova 和 Neutron 之间的交互流程 源计算节点与目的计算节点之间的交互流程 热迁移主要包括三个阶段: pre_live_migr ...

  4. OpenStack 虚拟机冷/热迁移功能实践与流程分析

    目录 文章目录 目录 前文列表 虚拟机迁移的应用场景 需要迁移的虚拟机数据类型 虚拟机迁移的存储场景 文件存储 块存储 非共享存储 迁移的类型 迁移的方式 执行虚拟机冷迁移 冷迁移日志分析 执行虚拟机 ...

  5. openstack虚拟机迁移的操作记录

    需求说明:计算节点linux-node1.openstack:192.168.1.8  计算节点linux-node2.openstack:192.168.1.17 这两个计算节点在同一个控制节点下( ...

  6. 开启vmotion,实现虚拟机可以在线迁移的选项

    先决条件: 1.vcenter5.5 2.vmotion服务开启 3.分布式交换机已经部署完毕 4.虚拟机在线迁移必须在web管理下,在vclient不可以

  7. 虚拟机在 OpenStack 里没有共享存储条件下的在线迁移

    虚拟机在 OpenStack 里没有共享存储条件下的在线迁移 本文尝试回答与 Live migration 相关的几个问题:Live migration 是什么?为什么要做 Live migratio ...

  8. 虚拟机在 OpenStack 里没有共享存储条件下的在线迁移[转]

    原文链接:http://www.ibm.com/developerworks/cn/cloud/library/1508_wangyx_openstacklivemigrate/ 迁移(Migrati ...

  9. OpenStack平台虚拟机实例在线迁移失败问题

    一.在线迁移时提示如下的报错 二.原因分析 通过kolla-ansible部署queens版本时,因为OEM的机器设备的UUID记录的一致,导致迁移时识别的是自身机器的UUID,导致迁移失败 三.问题 ...

随机推荐

  1. 最新windows 0day漏洞利用

    利用视屏:https://v.qq.com/iframe/player.html?vid=g0393qtgvj0&tiny=0&auto=0 使用方法 环境搭建 注意,必须安装32位p ...

  2. 用Rvm安装Ruby,Rails运行环境及常见错误解决方法

    一.安装Rvm 1.下载安装Rvm $ curl -L https://get.rvm.io | bash -s stable 此时可能出现错误:"gpg: 无法检查签名:找不到公钥&quo ...

  3. Broker节点

    在druid集群环境中 broker节点的作用是查询.它知道metadata 通过zookeeper发送到了集群中的哪个节点,从而能够准确的查询到.broker也把各个节点的结果汇聚到一个节点中.On ...

  4. MongoDB系列:把mongodb作为windows的服务来启动

    1.首先切换到mongodb安装目录下的bin目录,在控制台直接运行以下命令 "C:\Program Files\MongoDB\Server\3.0\bin\mongod.exe" ...

  5. servlet:从入门到实战学习(1)---全·环境配置

    最近公司忙加班学习,学校忙助教工作,博客鸽了好久,后端学习工作过程中学了好多东西,趁着工作之余得空补补博客,算是整理下学习的东西. javaweb的后端研发需要学习的是tomcat+servlet+j ...

  6. js继承与闭包(笔记)

    1.一切引用类型都是对象,对象时属性的集合:typeof null === 'object'(例外): 2.对象都是通过函数创建来的,比如var obj = new Object();typeof O ...

  7. mysql 优化方法

    1.选取最适用的字段属性 MySQL可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快.因此,在创建表的时候,为了获得更好的性能,我们可以将表中字段的宽度设得尽 ...

  8. 使用RandomAccessFile在两个java进程之间传递数据

    大部分情况下,我们面对在两个java进程只见传递数据的问题时,第一个想到的就是开server,然后通过socket收发消息.这方面有大量的框架可用,就不细说了.但如果两个进程是在一台机器上,那么还可以 ...

  9. windows和linux双系统修改启动项

    在windows系统的基础上再装linux系统的时候,电脑启动就会出现linux的启动引导项,默认的是进入linux.要使电脑默认进入windows只需要修改linux系统的启动引导文件(grub.c ...

  10. 转Fiddler 构造http请求

    今天使用Fiddler构造一个POST请求,server端的PHP脚本的 $_POST数组中怎么也获取不到值,后来偶然发现是因为缺少了一个http头:Content-Type: application ...