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. day002-HTML知识点总结:浏览器兼容性之指定IE浏览器使用chrome内核渲染页面

    今天再浏览大淘宝首页时,突然看到这么一个东东: ,顿时好费解,莫非万恶的IE浏览器认识到自己以往的罪孽,开始兼容chrome了??! 于是本着不懂就百度的神精,开始纵横于各大铁耙,勃哥,终于找到了许许 ...

  2. c中的可重入和不可重入函数

    可重入和不可重入 的基本概念 ---简介--- 可重入函数主要用于多任务环境中,一个可重入的函数简单来说就是可以被中断的函数,也就是说,可以在这个函数执行的任何时刻中断它,转入OS调度下去执行另外一段 ...

  3. backdrop-filter 和filter 写出高斯模糊效果 以及两者区别

    http://www.w3cplus.com/css3/advanced-css-filters.html: backdrop-filter:blur(10px);只支持ios端:只作用于当前元素: ...

  4. ios GCD简单介绍 后台运行~

    本从实践出发简单说明: 首先,gcd是Grand Central Dispatch的缩写,意为多线程优化技术,是苹果为多核处理优化的技术.使用简单.清晰. 多线程就分同步.异步方法如下: //异步线程 ...

  5. MapReduce处理流程

    MapReduce是Hadoop2.x的一个计算框架,利用分治的思想,将一个计算量很大的作业分给很多个任务,每个任务完成其中的一小部分,然后再将结果合并到一起.将任务分开处理的过程为map阶段,将每个 ...

  6. MyRocks DDL原理

    最近一个日常实例在做DDL过程中,直接把数据库给干趴下了,问题还是比较严重的,于是赶紧排查问题,撸了下crash堆栈和alert日志,发现是在去除唯一约束的场景下,MyRocks存在一个严重的bug, ...

  7. 【HDOJ 2150】线段交叉问题

    Pipe Time Limit : 1000/1000ms (Java/Other)   Memory Limit : 32768/32768K (Java/Other) Total Submissi ...

  8. 分布式锁与实现(一)——基于Redis实现

    概述 目前几乎很多大型网站及应用都是分布式部署的,分布式场景中的数据一致性问题一直是一个比较重要的话题.分布式的CAP理论告诉我们"任何一个分布式系统都无法同时满足一致性(Consisten ...

  9. ClickHouse 快速入门

    ClickHouse 是什么 ClickHouse 是一个开源的面向联机分析处理(OLAP, On-Line Analytical Processing) 的列式存储数据库管理系统. 在一个 &quo ...

  10. MySQL注射的过滤绕过技巧

    SQL注射的绕过技巧较多,此文仅做一些简单的总结. 最好利用的注射点: 支持Union 可报错 支持多行执行.可执行系统命令.可HTTP Request等额外有利条件 若非以上类型,则可能需要暴力猜解 ...