This post is based assumption that KVM as hypervisor, and Openstack is running in Grizzly on top of RHEL6.4.

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

Adding this line is to ask nova-compute  to utilize libvirt's true live migration function.

By default Migrations done by the nova-compute does not use libvirt's live migration functionality,
which means guests are suspended before migration and may therefore
experience several minutes of downtime.

>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

Block live migration seems a good solution if we don't have/want shared storage , but we still want to do some host level maintenance work without bring downtime to running VMs.

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

http://www.mirantis.com/blog/tutorial-openstack-live-migration-with-kvm-hypervisor-and-nfs-shared-storage/

(http://blog.sina.com.cn/s/blog_6330de3f01019trq.html)

《转》OpenStack Live Migration的更多相关文章

  1. openstack live migration性能分析

    http://blog.zhaw.ch/icclab/an-analysis-of-the-performance-of-live-migration-in-openstack/ http://blo ...

  2. OpenStack Live Migration

    About live migration of KVM virtual machines with NFS storage, from Mirantis blog: click this link w ...

  3. OpenStack nova VM migration (live and cold) call flow

    OpenStack nova compute supports two flavors of Virtual Machine (VM) migration: Cold migration -- mig ...

  4. Migration workstation vms to openstack kvm

    Migration workstation vms to openstack kvm 分别分成(磁盘是否拆分,vms 是否 有多个磁盘驱动器) 1, linux迁移 vmware workstatio ...

  5. Openstack虚拟机在线迁移(Live Migration)

    Openstack VM live migration can have 3 categories: -Block live migration without shared storage -Sha ...

  6. Setting up multi nodes live migration in Openstack Juno with devstack

    Setting up multi nodes live migration in Openstack Juno with devstack Summary Live migration overvie ...

  7. migration vmware vms to openstack kvm 修改vmware windows scsi to ide

  8. vmware vms migration to openstack

    Converting a VMware Workstation virtual machine to KVM Leave a commentPosted by rbgeek on August 13, ...

  9. VMware migration to openstack kvm

随机推荐

  1. 感觉Release有时比Debug要健壮

    评估文件夹大小的时候,直接跨线程操作UI界面,Debug崩溃,Release不崩溃. 更多的一种情况是,本机DEBUG下不崩溃,把RELEASE版本到别的机子上,立刻崩溃(登录框的进度条的对象为空,仍 ...

  2. 全球在一个 level 上思考的价值观和想法是一样的(转)

    近日,福布斯中文版总编辑周建工对话马云,谈到腾讯频繁的大笔收购,马云点评称腾讯收购的所有的案子,老百性都看得懂,这就错了.战略就像买股票一样,如果老太太都开始买股票了,一定有问题. 以下是对话内容,转 ...

  3. Hadoop集群配置(最全面总结)

    Hadoop集群配置(最全面总结) 通常,集群里的一台机器被指定为 NameNode,另一台不同的机器被指定为JobTracker.这些机器是masters.余下的机器即作为DataNode也作为Ta ...

  4. 距离变换DT

    距离变换:计算区域中的每个点与最接近的区域外的点之间距离,把二值图象变换为灰度图象. 对于目标中一个点,距离变换的定义为改点与目标边界最近的距离. 目标点离边界约近则值越小,转换的点越暗:越远,值越大 ...

  5. 极光IM使用教程-极光推送

    链接地址:http://jingyan.baidu.com/article/a948d65178a6ea0a2ccd2e7e.html 极光IM使用教程,如果您的 App 需要同时集成 Push 功能 ...

  6. PHP - 目录与文件

    第6章 目录与文件 学习要点: 1.目录操作 2.磁盘.目录和文件计算 3.文件处理 将相关的数据组织为文件和目录等实体,这一直是计算环境的核心概念.出于这个原因,程序员需要有一种方法来获得关于文件和 ...

  7. 怎样安装配置tomcat 8

    链接地址:http://jingyan.baidu.com/article/ff42efa91132a0c19e220208.html Apache tomcat 是目前最为流行的java网站开发的服 ...

  8. BZOJ 3314: [Usaco2013 Nov]Crowded Cows( 单调队列 )

    从左到右扫一遍, 维护一个单调不递减队列. 然后再从右往左重复一遍然后就可以统计答案了. ------------------------------------------------------- ...

  9. 利用T4模版生成EF实体

    直接上代码,只需要修改EF实体的地址就可以了. <#@ template language="C#" debug="false" hostspecific ...

  10. WCF技术剖析之十:调用WCF服务的客户端应该如何进行异常处理

    原文:WCF技术剖析之十:调用WCF服务的客户端应该如何进行异常处理 在前面一片文章(服务代理不能得到及时关闭会有什么后果?)中,我们谈到及时关闭服务代理(Service Proxy)在一个高并发环境 ...