沈林峰 (shenlinf@https://www.doczj.com/doc/3615982853.html,), 软件工程师, IBM
郭晋兵 (guojb@https://www.doczj.com/doc/3615982853.html,), 软件工程师, IBM
2008 年 8 月 14 日
动态分区迁移是基于 POWER6 的 IBM System p 服务器的一个新特性，该特性能够将运行中的逻辑分区从一台服务器迁移到另外一台，并且不影响用户的使用。集成虚拟化管理器（IVM）是除 HMC 外管理 IBM System p 服务器的另外一种方式，运行在 POWER6 上的 IVM 也支持动态分区迁移，不过在使用方式上和 HMC 上的分区迁移存在较大差别。本文主要介绍了如何在 IVM 上进行动态分区迁移，以及 IVM 和 HMC 上动态分区迁移的不同之处。
HMC（Hardware Management Console）是大家熟知的硬件管理控制台，系统管理员可以通过HMC 进行逻辑分区创建，编辑，删除以及分区状态的控制等操作。在 POWER6 出现以后，IBM System p 服务器提供了一个新的虚拟特性—动态分区迁移，利用该特性，用户能够将运行中的逻辑分区从一台服务器迁移到另外一台，并且不影响用户的使用。基于 HMC 的动态分区迁移在本文的参考资料中有详细的描述，用户可以通过这些资料来掌握 HMC 上的动态分区迁移操作。
IVM（Integrated Virtualization Manager）—集成虚拟化管理器是 IBM System p 上管理服务器的另一种方式，也支持动态分区迁移。因为该方式和 HMC 存在较大差别，因此动态分区迁移在这两种方式下也不尽相同。那么如何在 IVM 上进行动态分区迁移，两个平台上的分区迁移操作又有何不同呢？本文将逐一解答这些问题。
为了更好的阅读本文，要求读者对 IVM 的基本原理和操作界面有一个初步的认识，同时了解动态分区迁移的基本原理并熟悉 HMC 上动态分区迁移的配置和操作。读者可以通过阅读本文所提供的参考资料了解或熟悉这些方面的相关知识。如果读者有 IVM 和动态分区迁移的配置和使用经验，则能更进一步理解和掌握本文所描述的内容。
什么是集成虚拟化管理器
说到 IBM System p 的硬件管理控制台，大家熟知的还是 HMC。通过 HMC，可以管理多台System p 服务器，对它们进行分区管理，动态资源调节以及动态分区迁移等操作。HMC 尽管简化了对 System p 服务器的管理，但是还是存在一些缺点。首先，虽然 HMC 为管理从低端到高端各种类型的 System p 服务器提供了一套全面的解决方案，但是在一些简单的IT 环境（比如仅有一台低端服务器并且只需要简单的分区配置）中并不需要这么复杂的功能，一个能最大限度的支持快速部署和简化管理的方案更加适用于这种环境。其次，为了对一台低端服务器进行分区管理而购买一台价格并不算太便宜的 HMC 显得不是太划算。还有，HMC 不能管理基于 POWER 或 PowerPC 芯片的 IBM 刀片服务器。
IVM 解决了上述问题，它是一个简化版的 HMC，继承了大部分 HMC 功能。IVM 是 VIOS （Virutal I/O Server）的一个组成部分，VIOS 从 v1.2 开始支持 IVM，带有 IVM 功能的VIOS 是 HMC 和 VIOS 的一个集合体（如图 1 所示）。一个 IVM 只能管理一台服务器，基于 Web 的 GUI 操作界面简化了服务器管理，尤其是虚拟 I/O 资源的管理。由于功能受限，通常 IVM 用于中低端服务器。
图 1：集成虚拟化管理器
要激活 IVM 功能，VIOS 必须安装在出厂设置（Manufacturing Default Configuration）的服务器上（包括刀片服务器），该服务器不被 HMC 所管理。当 VIOS 作为第一个操作系统被安装在出厂设置的服务器上后，它接管了该服务器上所有的 I/O 资源，并激活 IVM 功能，系统管理员可以通过浏览器连接到 IVM 上进行虚拟 I/O 资源的划分，分配和删除，以及逻辑分区管理等操作。
在使用 HMC 管理服务器时，HMC 通过网络与 POWER5 或 POWER6 服务器上的 FSP（Flexible Service Processor）进行通信，进而跟 POWER Hypervisor 一起协作进行服务器管理。而 IVM 则通过一个特殊的虚拟设备 VMC（Virtual Management Channel）与 POWER Hypervisor 进行通信，VMC 和 Hypervisor 之间不需要任何网络连接。通过 VMC，IVM 能够进行逻辑分区配置，控制并显示分区状态，管理虚拟网络和存储资源等操作（如图 1 所示）。因为 IVM 依赖于 VMC 这种虚拟设备进行分区管理，因此一个 IVM 只管理一台服务器。只有 IVM 才有VMC 这种虚拟设备，HMC 管理下的普通 VIOS 不存在该设备（见清单 1）。
虽然 IVM 只是 VIOS 的一个组成部分，但是通常用户在使用 IVM 这个名词时，也指带有IVM 功能的 VIOS。读者可以通过上下文来区分 IVM 在不同情况下的具体含义。
清单 1：虚拟设备 VMC
实验环境
本文将通过图 2 所示的实验环境来说明如何利用 IVM 进行动态分区迁移。在 HMC 和 IVM 上进行动态分区迁移所需的系统配置大致相同，主要不同在于前者要求两个服务器连接在同一台 HMC 上，并通过 HMC 协调进行分区迁移，而后者则要求两台服务器分别由各自的 IVM 进行管理，分区迁移由两个 IVM 协调进行。
图 2：实验环境
该实验环境包含两个刀片服务器 uli13 和 uli14，网络和 SAN（Storage Area Network）。每个刀片服务器各安装一个 VIOS，由 IVM 进行管理。两个 VIOS 通过 SAN 共享存储子系统中的 LUN（Logical Unit Number），在 uli13 上通过 IVM 分配给两个逻辑分区 uli13lp1 和 uli13lp2。两个刀片服务器连接到同一个以太网中，uli13lp1 和 uli13lp2 通过 IVM 所提供的 VLAN（虚拟局域网）也连接到该网络。IVM 所在的 VIOS 的 MSP（Mover Service Partition）属性是默认打开的，没有任何选项用于打开或者取消 MSP 属性；这与 HMC 上的动态分区迁移不同，后者必须激活 VIOS 的 MSP 属性才能进行分区迁移。
在 IVM 上进行动态分区迁移
分区迁移前
图 3 和图 4 分别显示了分区迁移前源系统 uli13 和目标系统 uli14 上分区的状态，清单2 和清单 3 则分别显示了迁移前两个系统上虚拟磁盘的映射情况。分区 uli13 是 VIOS，是系统 uli13 上 IVM 的宿主分区；uli13lp1 是其中的一个分区，处于运行状态，占用了0.1 个处理器单元，1GB 内存和 5 个 SAN 磁盘 hdisk2/5/6/7/8，VIOS 使用虚拟设备vhost0 和 vtscsi0/1/2/3/4 进行虚拟磁盘映射；uli13lp2 是另一个分区，处于关闭状态，占用了 0.1 个处理器单元，1GB 内存和 5 个 SAN 磁盘 hdisk1/9/10/11/12，VIOS 使用虚拟设备 vhost1 和 vtscsi5/6/7/8/9 进行虚拟磁盘映射。分区 uli14 也是 VIOS，是系统uli14 上 IVM 的宿主分区；uli14 上没有其他分区，剩余的 1.8 个处理器单元和 2.69GB 内存能够满足迁移 uli13lp1 和 uli13lp2 所需的资源需求。服务器 uli13 和 uli14 上各有 13 个 SAN 磁盘，同名的磁盘被映射到 SAN 存储子系统中相同的 LUN。
由于 uli13lp1 处于运行状态，因此对它所做的分区迁移属于活动迁移；而 uli13lp2 处于关闭状态，因此分区迁移则属于非活动迁移。与 HMC 上的分区迁移类似，在 IVM 上活动迁移和非活动迁移的操作过程是一样的，IVM 根据分区的状态自动选择相应的迁移方式。本文以 uli13lp1 为例，讲解 IVM 上分区迁移的操作过程。
图 3：迁移前的 uli13
清单 2：迁移前 uli13 上的虚拟磁盘映射
$ lsdev | grep MPIO
hdisk0 Available MPIO Other FC SCSI Disk Drive
hdisk1 Available MPIO Other FC SCSI Disk Drive
hdisk2 Available MPIO Other FC SCSI Disk Drive
hdisk3 Available MPIO Other FC SCSI Disk Drive
hdisk4 Available MPIO Other FC SCSI Disk Drive
hdisk5 Available MPIO Other FC SCSI Disk Drive
hdisk6 Available MPIO Other FC SCSI Disk Drive
hdisk7 Available MPIO Other FC SCSI Disk Drive
hdisk8 Available MPIO Other FC SCSI Disk Drive
hdisk9 Available MPIO Other FC SCSI Disk Drive
hdisk10 Available MPIO Other FC SCSI Disk Drive
hdisk11 Available MPIO Other FC SCSI Disk Drive
hdisk12 Available MPIO Other FC SCSI Disk Drive
$ lsdev -virtual | grep -E "vhost|vtscsi"
vhost0 Available Virtual SCSI Server Adapter
vhost1 Available Virtual SCSI Server Adapter
vtscsi0 Available Virtual Target Device - Disk
vtscsi1 Available Virtual Target Device - Disk
vtscsi2 Available Virtual Target Device - Disk
vtscsi3 Available Virtual Target Device - Disk
vtscsi4 Available Virtual Target Device - Disk
vtscsi5 Available Virtual Target Device - Disk
vtscsi6 Available Virtual Target Device - Disk
vtscsi7 Available Virtual Target Device - Disk
vtscsi8 Available Virtual Target Device - Disk
vtscsi9 Available Virtual Target Device - Disk
$ lsmap -all
SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------ vhost0 U7998.61X.100390A-V1-C11 0x00000001
VTD vtscsi0
Status Available
LUN 0x8100000000000000
Backing device hdisk2
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400400000000
VTD vtscsi1
Status Available
LUN 0x8200000000000000
Backing device hdisk5
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400700000000
VTD vtscsi2
Status Available
LUN 0x8300000000000000
Backing device hdisk6
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400800000000
VTD vtscsi3
Status Available
LUN 0x8400000000000000
Backing device hdisk7
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400900000000
VTD vtscsi4
Status Available
LUN 0x8500000000000000
Backing device hdisk8
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400A00000000
SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------ vhost1 U7998.61X.100390A-V1-C13 0x00000000
VTD vtscsi5
Status Available
LUN 0x8100000000000000
Backing device hdisk1
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400300000000
VTD vtscsi6
Status Available
LUN 0x8200000000000000
Backing device hdisk9
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400B00000000
VTD vtscsi7
Status Available
LUN 0x8300000000000000
Backing device hdisk10
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400C00000000
VTD vtscsi8
Status Available
LUN 0x8400000000000000
Backing device hdisk11
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400D00000000
VTD vtscsi9
Status Available
LUN 0x8500000000000000
Backing device hdisk12
Physloc U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400E00000000 $
图 4：迁移前的 uli14
清单 3：迁移前 uli14 上的虚拟磁盘映射
hdisk3 Available MPIO Other FC SCSI Disk Drive
hdisk4 Available MPIO Other FC SCSI Disk Drive
hdisk5 Available MPIO Other FC SCSI Disk Drive
hdisk6 Available MPIO Other FC SCSI Disk Drive
hdisk7 Available MPIO Other FC SCSI Disk Drive
hdisk8 Available MPIO Other FC SCSI Disk Drive
hdisk9 Available MPIO Other FC SCSI Disk Drive
hdisk10 Available MPIO Other FC SCSI Disk Drive
hdisk11 Available MPIO Other FC SCSI Disk Drive
hdisk12 Available MPIO Other FC SCSI Disk Drive
$ lsdev -virtual | grep -E "vhost|vtscsi"
$ lsmap -all
$
迁移的验证
IVM 在任务列表（如图 5 所示）里面为分区迁移新增了“迁移性”这一个类别，包括“迁移”
和“状态”两个选项。使用“迁移“选项，可以验证和发起分区迁移。使用“状态”选项，可以随时查看分区迁移的状态，这样当分区迁移开始后，系统管理员就可以继续其他操作，而不需要等待迁移的完成。
图 5：IVM 任务列表
在使用“迁移”选项前，必须先选择要迁移的分区，而且每次只能选择一个分区。每个分区都是可选的，包括 VIOS uli13 在内，虽然迁移 VIOS 是不恰当的。如果选择了 VIOS，那么 IVM 在验证分区迁移的时候就会报错，从而避免了不恰当的迁移请求。因为对于被选择的分区，管理员可以从任务列表选择多种不同的操作，因此 IVM 无法预先知道是否要进行分区迁移，所以不可能在分区列表里面禁止选择 VIOS 的操作，而是在选择“迁移”功能之后才进行判断。这里我们选择迁移的是 uli13lp1（如图 5 所示），在任务列表里面选择了“迁移”选项后，用户看到的是一个验证和迁移页面（如图 6 所示），其中包含几个字段和按钮。
图 6：验证和迁移页面
字段包括远程 IVM 的主机名（注意，不是目标系统的名称）或 IP 地址，以及登陆该远程系统所需的用户名和密码。有趣的是，远程 IVM 字段还标明了“HMC”字样，这可能意味着将来即使在 HMC 上进行动态分区迁移也不要求两台服务器必须由同一台 HMC 来管理，这样一来，由不同 HMC 管理的服务器之间，以及由 HMC 和 IVM 所管理的服务器之间也可以进行分区迁移，从而增加了分区迁移的灵活性。不过目前的动态分区迁移还不支持这一功能。按钮用于验证分区迁移和开始分区迁移。HMC 也为分区迁移提供了验证和迁移两个功能，系统管理员可以选择先做验证，然后再开始分区迁移，也可以不使用验证功能，而直接开始分区迁移。由于分区迁移向导其中的一个环节就是进行自动验证，因此无论管理员采用什么方式，HMC 总能保证在迁移开始之前进行验证，尽早发现并提示管理员修复问题，提高分区迁移的效率。相比于 HMC，在 IVM 上进行验证和迁移所需的操作被大大简化了，用户只需要点击“验证”和“迁移”按钮就可以进行分区迁移的验证和开始分区迁移。IVM 上的分区迁移在开始阶段也同样包含了对迁移的验证，如果验证失败了，IVM 停止分区迁移，并报告错误信息。虽然分区迁移会自动进行验证，因此用户可以不用经过验证而直接开始分区迁移，但是还是建议用户在开始迁移之前事先进行验证。
填写完上述字段后，按下“验证”按钮就开始了分区迁移的验证。在验证过程中，IVM 显示一个等待对话框（如图 7 所示），过一小段时间后，验证完成，IVM 显示验证结果。如果验证没有发现问题，那么 IVM 显示“操作已经成功完成”（如图 8 所示）；如果发现错误，管理员可以通过 IVM 所显示的错误信息去修复问题，然后再次进行验证。
图 7：分区迁移的验证
图 8：验证结果
开始分区迁移
验证成功后，按下“迁移”按钮就开始进行分区迁移了（如图 9 所示）。分区迁移所需的时间长短视分区物理内存大小，以及系统所承受的压力等因素而定。对分区 uli13lp1 进行的迁移是活动迁移，因此所用的时间通常比 uli13lp2 上的非活动迁移来得长。图 9 所显示
的是 uli13lp1 的迁移状态，用户可以通过该页面监视迁移的进度。该页面还提供了“停止”和“恢复”两个按钮，通过前者，可以取消当前正在进行的分区迁移，通过后者，可以在迁移出现问题后回退迁移过程，修复问题，使系统恢复到正常状态。
图 9：分区迁移的状态
在分区迁移的过程中，系统管理员不必一直监视着迁移状态，可以在 IVM 上继续其他方面的系统维护工作。图 10 和图 11 分别显示的是 uli13 和 uli14 上 IVM“查看 / 修改分区”页面的内容，可以看到 IVM 正在迁移 uli13lp1，状态栏显示“迁移－正在运行”，迁移过程在 uli14 创建了新的分区 uli13lp1，使用了相同数量的 CPU 和内存资源。这两幅图是迁移开始时的截图，这时候源系统 uli13 上 uli13lp1 分区的运行时状态还没有被完全迁移到目标系统 uli14，迁移过程还没有停止源分区的运行并激活目标分区，因此在 uli13 上仍旧可以看到 uli13lp1 正常运行时的参考码“Linux ppc64”，而在 uli14 上，uli13lp1 则显示了一个迁移中的中间参考码。类似的，源分区显示了 13.47 天“正常运行时间”和
0.03 个“利用的处理器单元数”，而目标分区因为还没有开始运行，因此不显示这些信息。
图 10：迁移中的 uli13
图 11：迁移中的 uli14
分区迁移后
当分区迁移成功后，我们可以在 uli13 和 uli14 上分别看到如图 12 和图 13 所示的分区状态。在源系统 uli13 上，迁移过程停止并删除了 uli13lp1，因此该分区不复存在，只剩下 VIOS 和分区 uli13lp2。在目标系统 uli14 上，迁移过程创建并激活了 uli13lp1，因此可以看到该分区正在运行中：首先分区状态由“迁移－正在进行”变成了“正在运行”，其次参考码也从不断变化的中间值变成“Linux ppc64”，最后正常运行时间和利用的处理器单元数也显示出来了。这表明 uli13lp1 已经从源系统 uli13 成功的迁移到目标系统 uli14 上了。
再看看虚拟磁盘的映射情况。在 uli13 上，uli13lp2 的虚拟磁盘映射仍然存在，而
uli13lp1 的虚拟磁盘映射则被解除掉了，甚至它所占用的虚拟设备 vhost0 和
vtscsi0/1/2/3/4 也被删除掉了（见清单 4）。在 uli14 上则增加了 uli13lp1 的虚拟磁盘映射，5 个 SAN 磁盘 hdisk2/5/6/7/8 被映射给了该分区，显然这与原来的磁盘映射关系是相同的，同时虚拟设备 vhost0 和 vtscsi0/1/2/3/4 也被创建并用于虚拟磁盘映射（见清单 5）。通过对比清单 5 和清单 2，我们可以发现两个系统上映射给 uli13lp1 的 SAN 磁盘都是一样的，甚至虚拟设备的名称也都是一样的。不过虚拟设备的名称并不要求必须是一样的，这要看迁移前目标系统上虚拟设备资源的使用情况，如果源系统上所使用的虚拟设备名称在目标系统上已经被占用了，那么分区迁移时只能使用其他的设备名称，只要保证磁盘映射关系相同就可以了。在本文所举的例子中，由于 uli14 在迁移前除了 VIOS 外没有其他分区，uli13lp1 在 uli13 上所占用的虚拟设备名称在 uli14 上并没有被使用，因此迁移过程在目标系统上创建的虚拟设备也使用了相同的名称。
图 12：迁移后的 uli13
清单 4：迁移后 uli13 上的虚拟磁盘映射
hdisk1 Available MPIO Other FC SCSI Disk Drive
hdisk2 Available MPIO Other FC SCSI Disk Drive
hdisk3 Available MPIO Other FC SCSI Disk Drive
hdisk4 Available MPIO Other FC SCSI Disk Drive
hdisk5 Available MPIO Other FC SCSI Disk Drive
hdisk6 Available MPIO Other FC SCSI Disk Drive
hdisk7 Available MPIO Other FC SCSI Disk Drive
hdisk8 Available MPIO Other FC SCSI Disk Drive
hdisk9 Available MPIO Other FC SCSI Disk Drive
hdisk10 Available MPIO Other FC SCSI Disk Drive
hdisk11 Available MPIO Other FC SCSI Disk Drive
hdisk12 Available MPIO Other FC SCSI Disk Drive
$ lsdev -virtual | grep -E "vhost|vtscsi"
vhost1 Available Virtual SCSI Server Adapter
vtscsi5 Available Virtual Target Device - Disk
vtscsi6 Available Virtual Target Device - Disk
vtscsi7 Available Virtual Target Device - Disk
vtscsi8 Available Virtual Target Device - Disk
vtscsi9 Available Virtual Target Device - Disk
$ lsmap -all
SVSA Physloc Client Partition ID
--------------- -------------------------------------------- ------------------
vhost1 U7998.61X.100390A-V1-C13 0x00000000
VTD vtscsi5
Status Available
LUN 0x8100000000000000
Backing device hdisk1
Physloc
U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400300000000
VTD vtscsi6
Status Available
LUN 0x8200000000000000
Backing device hdisk9
Physloc
U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400B00000000
VTD vtscsi7
Status Available
LUN 0x8300000000000000
Backing device hdisk10
Physloc
U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400C00000000
VTD vtscsi8
Status Available
LUN 0x8400000000000000
Backing device hdisk11
Physloc
U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400D00000000
VTD vtscsi9
Status Available
LUN 0x8500000000000000
Backing device hdisk12
Physloc
U78A5.001.WIH0402-P1-C6-T1-W5005076303030053-L4011400E00000000 $
图 13：迁移后的 uli14
清单 5：迁移后 uli14 上的虚拟磁盘映射
hdisk11 Available MPIO Other FC SCSI Disk Drive
hdisk12 Available MPIO Other FC SCSI Disk Drive
$ lsdev -virtual | grep -E "vhost|vtscsi"
vhost0 Available Virtual SCSI Server Adapter
vtscsi0 Available Virtual Target Device - Disk
vtscsi1 Available Virtual Target Device - Disk
vtscsi2 Available Virtual Target Device - Disk
vtscsi3 Available Virtual Target Device - Disk
vtscsi4 Available Virtual Target Device - Disk
$ lsmap -all
SVSA Physloc Client Partition ID
--------------- --------------------------------------------
------------------
vhost0 U7998.60X.100E7DA-V1-C11 0x00000001
VTD vtscsi0
Status Available
LUN 0x8100000000000000
Backing device hdisk2
Physloc
U78A5.001.WIH1106-P1-C10-T1-W5005076303030053-L4011400400000000
VTD vtscsi1
Status Available
LUN 0x8200000000000000
Backing device hdisk5
Physloc
U78A5.001.WIH1106-P1-C10-T1-W5005076303030053-L4011400700000000
VTD vtscsi2
Status Available
LUN 0x8300000000000000
Backing device hdisk6
Physloc
U78A5.001.WIH1106-P1-C10-T1-W5005076303030053-L4011400800000000
VTD vtscsi3
Status Available
LUN 0x8400000000000000
Backing device hdisk7
Physloc
U78A5.001.WIH1106-P1-C10-T1-W5005076303030053-L4011400900000000 VTD vtscsi4
查看迁移状态
上面说到系统管理员可以在分区迁移开始后在 IVM 上继续其他方面的系统管理工作，而不需要一直监视着分区迁移的状态。那么通过什么途径能够再次查看分区迁移的状态呢？
第一种方法是使用任务列表中“状态”选项（如图 14 所示）。在源系统的 IVM 上选择了该功能后，用户就可以再次看到分区迁移的状态页面了（如图 15 所示），通过该页面用户可以监视，停止或者恢复分区迁移。
图 14：IVM 任务列表
图 15：分区迁移的状态
另外一种方法是使用“服务管理”中的“监视任务”功能（如图 16 左部所示）。在源系统上选择了该功能后，IVM 会在窗口的右部显示所有任务的一个列表，其中包括分区迁移任务（如图 16 右部所示）。每个分区迁移任务只对应列表中的一项，迁移状态被持续的更新到该项中，因此每次看到的都是最新的状态。选择其中某个分区迁移任务，点击“属性”按钮，就可以看到当前分区迁移的状态（如图 16 右下角窗口所示）。图 16 所示的是 uli13lp1 迁移成功后的状态，如果在迁移过程中查看该项，则可以看到迁移的进度。
图 16：分区迁移的状态
命令行界面
除了上述 GUI 界面可用于分区迁移外，IVM 还提供了命令行界面（CLI）。GUI 界面使得系统管理员能够更加直观方便的进行分区迁移操作，而命令行界面则对于有计划的分区迁移和自动测试特别有用。
与 HMC 一样，IVM 也提供了 migrlpar 和 lslparmigr 两个新命令用于分区迁移。命令migrlpar 用于检查，开始，停止分区迁移并从错误中恢复；命令 lslparmigr 用于查看分区迁移的状态。不过与 HMC 相比，IVM 提供的命令在语法上稍有不同。从清单 6 和清单 7 可以看出，IVM 命令行主要增加了 --ip
清单 6：IVM 上分区迁移命令的语法
migrlpar [-o s | m | r | v -m system> [-t -ip ID>[-n data file> | -i "input data>"] [-w time>] [-d -async] [-v] [--force] [--stderr] [--help] lslparmigr -r manager | lpar | msp | procpool | sys | virtualio [-m [--ip address> [-u username>]] [--filter " [-F 清单 7：HMC 上分区迁移命令的语法 migrlpar -o {m | r | s | v} -m managed-system [-t target-managed-system] {-p partition-name | --id partition-ID} [-n profile-name] [{-f input-data-file | -i "input-data"}] [-w wait-time] [-d detail-level] [-v] [--force] [--help] lslparmigr -r {lpar | msp | procpool | sys | virtualio} -m managed-system [-t target-managed-system] [--filter "filter-data"] [-F [attribute-names] [--header]] [--help] 选项 --ip 用于指明目标 HMC/IVM 的主机名或者 IP 地址，该选项与 -t 清单 8：uli14 的主机名和系统名称 图 17：uli14 的系统名称 选项 -u 用于指明登陆目标 HMC/IVM 所需的用户名。如果分区迁移命令需要用户名但是用户没有提供 -u 选项，那么迁移过程会自动使用执行该命令的用户名。 如果使用了 --async 选项，那么命令 migrlpar 在迁移过程中完成迁移的验证后就马上返回，迁移过程继续进行，这样系统管理员就不需要等待整个迁移过程的完成，可以进行其他操作。如果系统管理员在做完其他操作后想查看分区迁移的状态，可以使用 lslparmigr 命令（见表单 9）。当迁移过程还在继续进行，那么 lslparmigr 显示“Migration Starting”状态；如果迁移已经完成，那么 lslparmigr 显示“Not Migrating”状态。 清单 9：用命令行进行分区迁移 用 migrlpar 进行分区迁移，使用 --async 选项 $ hostname uli13 $ lssyscfg -r sys -F name Server-7998-61X-SN100390A $ migrlpar -o m -m Server-7998-61X-SN100390A -t Server-7998-60X-SN100E7DA --ip uli14 -u padmin -p uli13lp1 --async $ 使用 --async 选项的 migrlpar 返回后迁移继续进行，可以使用 lslparmigr 查看迁移状态 $ lslparmigr -r lpar -m Server-7998-61X-SN100390A --filter "lpar_names=uli13lp1" name=uli13lp1,lpar_id=2,migration_state=Migration Starting,migration_type=active,dest_sys_name=Server-7998-60X-SN100E7DA,dest_lpa r_id=2, source_msp_name=uli13,source_msp_id=1,dest_msp_name=uli14,dest_msp_id=1, bytes_transmitted=2366013,bytes_remaining=1090875392,remote_manager=uli14, remote_user=padmin $ 等待一段时间，分区迁移完成，再使用 lslparmigr 查看迁移状态 $ lslparmigr -r lpar -m Server-7998-61X-SN100390A --filter "lpar_names=uli13lp1" name=uli13lp1,lpar_id=2,migration_state=Not Migrating $ 用 migrlpar 进行分区迁移，不使用 --async 选项，命令返回后马上用 lslparmigr 查看 IVM 和 HMC 上分区迁移的比较 从上述讨论中我们可以看到，相对于 HMC，IVM 上的动态分区迁移相对简化，这与 IVM 的设计原则是一致的。IVM 和 HMC 上的分区迁移所需的配置基本相同，比如对 System p 平台，Firmware 和 VIOS 版本，网络和外部存储的配置，RMC（Resource Monitoring and Control）daemon，以及被迁移分区所运行的操作系统版本的要求是相同的，而且被迁移分区都不能属于任何一个“Partition workload groups”；而由于 IVM 和 HMC 在管理界面的截然不同，因此操作过程相差较大。下面列举的是两种管理方式下动态分区迁移不同点的一些对比： ?服务器的管理：由 HMC 管理时，源和目标服务器必须由同一台 HMC 来管理，分区迁移由该 HMC 来协调；由 IVM 管理时，每台服务器由各自的 IVM 进行管理，分区迁移由两个 IVM 协调进行。 ?MSP 属性：在 HMC 上，需要激活 VIOS 上的 MSP 属性才能进行分区迁移；而在 IVM 上，MSP 是默认打开的，不需要激活。 ?MSP 的个数：在 HMC 上，一个系统上可以存在多个 MSP，每个 MSP 都可以用于分区迁移；而在 IVM 上，VIOS 就是 MSP，有且仅有一个 MSP。 ?GUI 界面：GUI 操作界面的截然不同是显而易见的，不过两者之间还是有不少相似之处，比如都提供验证和迁移功能等。 ?CLI 界面：相对于 HMC 而言，IVM 的用于分区迁移的命令主要增加了 --ip ?-m 和 -t 选项的可选性：在 HMC 上使用命令 migrlpar 进行动态分区迁移时，-m 而在 IVM 上，-m 该选项在进行分区迁移时是必须的（见清单 10）。 清单 10：-m 和 -t 选项的可选性 ?用户名和密码：由于同一台 HMC 管理着参与动态分区迁移的两台服务器，因此迁移的时候不需要指定登陆到目标 HMC 的用户名和密码；而当两台服务器分别由两个不同的 IVM 来管理时，就需要指定登陆到目标 IVM 的用户名和密码。 ?Profile：在 HMC 上进行分区迁移时，用户可以指定一个 profile 名称用于记录迁移后分区当前的配置，保留现有的 profile。而在 IVM 上，因为每个逻辑分区有且仅有一个 profile，因此不需要指定新的 profile 名称，分区迁移过程总是把迁移后的分区配置记录在该 profile 里面；所以，IVM 的 GUI 界面并不提供输入新的 profile 的域，并且命令 migrlpar 所提供的“-n profile-name”选项并不起作用。 ?等待时间（wait time）：该参数是指等待由 HMC 或 IVM 向被迁移分区所发出的命令执行完成所花的最长时间（以分钟为单位）。在 HMC 上，分区迁移的 GUI 向导 提供了该域，允许用户设定新的等待时间；而在 IVM 上，GUI 界面并不提供该域，因此只能使用默认的等待时间。当在 HMC 或者 IVM 上使用命令行进行分区迁移时，可以通过“-w ?其他特性：在 HMC 上进行分区迁移要避免使用“Barrier Synchronization Register”和“Huge pages”等特性，否则迁移验证会失败；而因为简化设计的缘故，IVM 并没有提供这些特性，因此也就不需要检查分区是否使用这些特性了。 这里还需要澄清 VASI（Virtual Asynchronous Services Interface）和物理 I/O 设备这两点。 ?VASI 是 MSP 和 Hypervisor 之间进行通信的一个虚拟设备。在源系统上，MSP 通过 VASI 从 Hypervisor 获取分区的运行时状态，然后通过网络传送给目标系统的 MSP；在目标系统上，MSP 通过 VASI 把分区的运行时状态传送给 Hypervisor。在 IVM 和 HMC 两种情况下，VASI 都是必须的。在早期支持动态分区迁移的 VIOS 版 本（比如 VIOS 1.5.0.0）中，VASI 是需要用户自己去创建的；而在较新版本的 VIOS （比如 VIOS 1.5.2.0）中，VASI 是系统自动创建的。 ?动态分区迁移对物理 I/O 设备的迁移做了限制：活动迁移不能使用物理设备，在迁移开始之前必须手动把所有物理设备删除掉；非活动迁移可以使用物理设备，但是 迁移过程会自动把物理设备删除掉，因此如果要在目标分区使用物理设备，那么需要在迁移完成之后手动把物理设备加入目标分区的配置文件。在 HMC 上，逻辑分区拥有物理 I/O 设备是很正常的事情，用户在进行分区迁移之前要按照上述要求去处理物理设备的使用。版本较低的 VIOS，比如 VIOS 1.5.0.0 上的 IVM 只支持虚拟设备，除 VIOS 外，其他分区所使用的网卡和磁盘都是虚拟的；而从 VIOS 版本 1.5.1.1 开始，IVM 可以将物理设备直接分配给分区来使用，这时用户也同样需要 注意上述要求。 小结 本文介绍了如何在 IBM 集成虚拟化管理器—IVM 上进行动态分区迁移，包括迁移所需的配置，迁移的验证，发起和状态的查看，以及用于迁移的命令。本文还对比了在 IVM 和 HMC 上的分区迁移，虽然两者的差别不是非常大，但是管理界面上的截然不同使得两者的操作方式差别较大。与 HMC 相比，IVM 上的动态分区迁移操作过程较为简化，这与 IVM 的设计原则是一致的。 声明：本文仅代表作者个人之观点，不代表 IBM 公司之观点。 KVM 虚拟机在物理主机之间迁移的实现 如何从一台物理主机上迁移 KVM 虚拟机到另一台物理主机 郭晋兵, 软件工程师, IBM 丛彬彬, 软件工程师, IBM 简介：虚拟机的迁移使资源配置更加灵活，尤其是在线迁移技术，提高了虚拟服务器的可用性和可靠性。本文是虚拟机迁移技术漫谈系列的第二部分，详细介绍 KVM 虚拟机在物理主机之间的静态迁移和在线迁移特性，而且包括基于数据块的在线迁移实现。 发布日期： 2010 年 11 月 04 日 级别：初级 访问情况： 15504 次浏览 评论： 3 (查看 | 添加评论 - 登录) 平均分 (37个评分) 为本文评分 前言 虚拟机的迁移技术为服务器的虚拟化提供简便的方法。目前流行的虚拟化产品VMware，Xen，Hyper-V，KVM 都提供各自的迁移工具。其中 Linux 平台上开源的虚拟化工具 KVM 发展迅速，基于 KVM 的虚拟机的迁移特性也日趋完善。本文全面介绍 KVM 虚拟机在不同的应用环境下的静态迁移（离线迁移）和动态迁移（在线迁移），并且在最新发布的 Suse Linux Enterprise Edition 11 SP1 上分别演示如何应用 libvirt/virt-manager 图形化工具和基于命令行的 qemu-kvm 工具进行迁移操作。 V2V 虚拟机迁移的介绍 V2V 虚拟机的迁移是指在 VMM（Virtual Machine Monitor）上运行的虚拟机系统，能够被转移到其他物理主机上的 VMM 上运行。VMM 对硬件资源进行抽象和隔离，屏蔽了底层硬件细节。而迁移技术的出现，使得操作系统能在不同的主机之间动态的转移，进一步解除软，硬件资源之间的相关性。本系列的第一篇文章“虚拟机迁移技术漫谈”中，介绍了 V2V 迁移的三种方式，本文将更加详细的说明三种方式的不同和实现方法。 V2V 迁移方式的分类 静态迁移 静态迁移：也叫做常规迁移、离线迁移（Offline Migration）。就是在虚拟机关机或暂停的情况下从一台物理机迁移到另一台物理机。因为虚拟机的文件系统建立在虚拟机镜像上面，所以在虚拟机关机的情况下，只需要简单的迁移虚拟机镜像和相应的配置文件到另外一台物理主机上；如果需要保存虚拟机迁移之前的状态，在迁移之前将虚拟机暂停，然后拷贝状态至目的主机，最 后在目的主机重建虚拟机状态，恢复执行。这种方式的迁移过程需要显式的停止虚拟机的运行。从用户角度看，有明确的一段停机时间，虚拟机上的服务不可用。这种迁移方式简单易行，适用于对服务可用性要求不严格的场合。 共享存储的动态迁移 动态迁移（Live Migration）：也叫在线迁移（Online Migration）。就是在保证虚拟机上服务正常运行的同时，将一个虚拟机系统从一个物理主机移动到另一个物理主机的过程。该过程不会对最终用户造成明显的影响，从而使得管理员能够在不影响用户正常使用的情况下，对物理服务器进行离线维修或者升级。与静态迁移不同的是，为了保证迁移过程中虚拟机服务的可用，迁移过程仅有非常短暂的停机时间。迁移的前面阶段，服务在源主机的虚拟机上运行，当迁移进行到一定阶段，目的主机已经具备了运行虚拟机系统的必须资源，经过一个非常短暂的切换，源主机将控制权转移到目的主机，虚拟机系统在目的主机上继续运行。对于虚拟机服务本身而言，由于切换的时间非常短暂，用户感觉不到服务的中断，因而迁移过程对用户是透明的。动态迁移适用于对虚拟机服务可用性要求很高的场合。 目前主流的动态迁移工具，VMware 的 VMotion，Citrix 的XenMotion，他们都依赖于物理机之间采用 SAN （storage area network）或 NAS（network-attached storage）之类的集中式共享外存设备，因而在迁移时只需要进行虚拟机系统内存执行状态的迁移，从而获得较好的迁移性能。 将实体机迁移到VMware虚拟机原来如此容易分类：摆电脑的聊斋 | 标签：虚拟机vmware ghost converter 驱动 2013-07-28 22:57阅读(3970)评论(0)在虚拟化大行其道并有一统天下趋势的今天，相信很多企业都准备运用虚拟化这一综合解决方案，可摆在技术人员面前的却有这样一个问题：如何将现有的服务器系统原封不动的迁移到虚拟机中去？ 前几天我在windows2003环境下做了这方面的尝试，试用过很多 方法，最终发现一个最简单的方法可实现，虚拟机已运行几日，一切 正常。现记录下来分享，避免大家再像我一样走那么多不必要的弯路。 首先，做好充分的准备工作： 1、在承载虚拟机的物理宿主机上安装VMware workstation虚 拟机系统(我安装的是９.0中文版)，设置好常规参数(也可以什么参 数都不设置)、准备好虚拟机存放文件夹并将其设置为隐藏式共享、 权限设置为everyone和guests(避免未启用本地安全策略中的“将 everyone权限应用于匿名用户”)可读取和写入，以备存放转换好的 虚拟机文件。 利用网络地址存放转换后的文件至少有两个好处：转换和存放一 次完成、完成后即可使用，不需要再复制以节省时间；速度更快，1000M 网络传输的速度远大于硬盘内的数据交换速度。 2、在即将被虚拟的实体机上安装 VMware vCenter Converter Standalone软件，选择本地安装(我 安装的是5.0中文版)。 3、退出实体机上的杀毒软件、关闭正在下载的更新、清理系统垃圾和不需运行的进程(正在运行的服务不用停止、也不需要整理磁盘)。 接着，执行实体机到虚拟机的转换工作： 1、打开Converter软件，登录到本机，执行“转换计算机”进入转换向导；源系统为已打开电源的计算机、此本地计算机；若数据不是很多建议选择本地所有分区，否则不能保留原有的硬盘分区结构，以后变更会稍显麻烦；设置转换目的地址为刚才共享的路径，形式为“\\192.168.x.x\sharename$”；其他选项使用默认值即可，尤其是勾选所运行的服务环节。我20多G的内容转换及存储仅10分多钟就完成了，速度确实很快。 在转换完成后，实体机的界面可能会变得比较吓人(因为在转换时去除了一些驱动及有可能不兼容的内容，以便于系统封装)，此时不要惊慌，直接重启实体机它会自行恢复。 2、修改计算机名和IP地址，避免虚拟机启动后出现“网络上有重名”和“IP地址冲突”。 最后，运行该虚拟机： 1、在承载虚拟机的宿主机上打开VMware workstation，选择打开虚拟机，路径为刚设置共享的文件夹，这里要注意一点：若实体机仍在运行且未改名，须将虚拟机的网络适配器属性设置为NAT方式(待设置完成、无冲突后再改为桥接方式)，避免首次开机提示“网络上有重名”而无法登录，然后再打开虚拟机电源。 虚拟机迁移 静态迁移是指在虚拟机关闭或暂停的情况下，将源宿主机上虚拟机的磁盘文件和配置文件拷贝到目标宿主机上。这种方式需要显式的停止虚拟机运行，对服务可用性要求高的需求不合适。 动态迁移无需拷贝虚拟机配置文件和磁盘文件，但是需要迁移的主机之间有相同的目录结构放置虚拟机磁盘文件，可以通过多种方式实现，本例采用基于共享存储动态迁移，通过NFS（Network File System网络文件系统）来实现。 源宿主机：Ubuntu16.04操作系统，下文中以“节点1”表示，NFS挂载目录/home/kvm。 目标宿主机：Ubuntu16.04操作系统，下文中以“节点2”表示，NFS挂载目录/home/kvm。 基于QEMU的动态迁移虚拟机镜像文件为ubuntu14.04.img。 NFS服务器：Ubuntu16.04操作系统，服务目录为/mnt/nfs/。 1、NFS服务器配置 (1)KVM虚拟机动态迁移无需拷贝虚拟机配置文件和磁盘文件，但是需要迁移的 主机之间有相同的目录结构放置虚拟机磁盘文件（本例为“/home/kvm”目录），这里的动态迁移是基于共享存储动态迁移，通过NFS来实现，需要QEMU 0.12.2以上版本支持。可以使用“qemu-img --help|grep version”来查看 安装的QEMU的版本号。 (2)在VMware中将宿主机克隆，“管理”----“克隆”。源宿主机为节点1，克 隆的机器作为目标宿主机，为节点2。克隆步骤如下： (3)修改节点2中的IP地址（修改为和你的节点1同一网段的IP）。只需修改 IP即可，其他不用改动，命令如下： root@ubuntu:~# vim /etc/network/interfaces 修改完毕后，重启网络 root@ubuntu:~# /etc/init.d/networking restart [ ok ] Restarting networking (via systemctl): networking.service. (4)在节点2上安装NFS服务器。使用命令“sudo apt-get install nfs-kernel-server nfs-common”下载安装NFS，kernel-server相当于server端,common是client端，如图所示： 云计算中虚拟机实时迁移技术的鲁棒性研究 云计算中采用虚拟机实时迁移技术实现数据中心资源的动态调度和管理。作为虚拟机实时迁移技术的核心，实时迁移算法目前虽然在运行性能方面表现良好，但在抗主机故障、网络故障、恶意攻击等鲁棒性方面仍存在不足，进而在这些异常或危险情况下无法保证实时迁移过程顺利完成，甚至干扰虚拟机内业务正常运行。本文对虚拟机实时迁移技术中关键算法的鲁棒性进行分析研究，指出其中所存在的问题，并提出相应的解决思路。 【关键词】虚拟机实时迁移云计算鲁棒性 1 引言 云计算将IT 软硬件资源通过网络以服务的模式提供给最终用户，使得用户能够按需使用、计量付费。基于laaS（基础设施即服务）云计算平台的应用较为普遍，其主要采用虚拟化技术将CPU存储、硬盘、网络等资源以虚拟机的访问进行封装、分配、调度及管理。用户在云平台提供的虚拟机上能够快速、高效、廉价地搭建自己的lT 基础设施平台。 虚拟机实时迁移是laaS云计算平台的一项关键核心技术， 其基于实时迁移算法将某台物理主机上正在运行的虚拟机在线地移动到另一台物理主机上，期间虚拟机正常提供对外服务。当前主流的实时迁移算法虽然在运行性能方面较为良好，但是在抗主机故 障、网络抖动、恶意攻击等鲁棒性方面还存在一些问题。本文分析了实时迁移算法所存在的鲁棒性问题并提出了相应的几个对策。 2 实时迁移算法由于目前数据中心多采用共享存储架构，因此实时迁移的主要对象是虚拟机的内存镜像、vCPU及I/O寄存器状态数 据。主流的实时迁移算法根据迁移对象先后次序的不同划分为预拷贝Pre-copy和后拷贝Post-copy两种。 Pre-copy 是最先出现的实时迁移算法，其主要运行流程如下： （1）实时迁移过程开始，源宿主机与目标宿主机建立连接，目标宿主机上预留虚拟机资源； （2）首先将虚拟机的整个内存镜像，即所有内存页面传输过去； （3）进入一个迭代拷贝阶段，每个迭代轮传输上一轮中产生的内存脏页； （4）循环步骤3，直到剩余脏页足够小或者达到最大迭代次数，退出迭代过程； （5）进入停机拷贝阶段，将vCPU寄存器及I/O设备状 态数据连同剩余脏页一齐传输到目标宿主机； 6）在宿主机上恢复虚拟机运行，实时迁移结束 Post-copy 算法出现较晚，其主要运行流程如下： （1）实时迁移过程开始，源宿主机与目标宿主机建立连 数据迁移服务V200R100C00交付材料VMware虚拟机数据迁移方案 华为技术有限公司 版权所有侵权必究 修订记录 目录 第1章数据迁移前必读 (1) 1.1概述 (1) 1.2读者对象 (1) 1.3适用场景 (1) 1.4注意事项 (2) 第2章数据迁移流程 (3) 第3章数据迁移前准备 (4) 3.1迁移环境准备 (4) 3.1.1 准备参考文档 (4) 3.1.2 查询系统信息 (4) 3.1.3 获取所需的软件和工具 (5) 3.1.4 检查系统及设备运行状态 (5) 3.2 配置目标存储 (5) 3.2.1 配置热备盘 (6) 3.2.2 创建RAID组及划分LUN (6) 3.3 数据备份 (6) 第4章数据迁移方案 (8) 4.1添加目标存储映射 .................................................................................. 错误！未定义书签。 4.1.1 更改设备物理连接 ........................................................................ 错误！未定义书签。 4.1.2 映射目标存储LUN给主机 (10) 4.1.3 在服务器上配置虚拟磁盘.............................................................. 错误！未定义书签。 4.2迁移数据................................................................................................. 错误！未定义书签。 4.3迁移完成后移除源存储 (16) 4.4同步备机................................................................................................. 错误！未定义书签。 4.5添加目标存储多路径 (22) 4.6 调测业务系统 (32) 第5章回退方案 (33) 5.1 回退场景 (33) 5.1.1 数据备份与恢复； (33) 5.1.2 割接失败导回方案 (33) 5.2 回退步骤 (33) Vmware vSphere常见问题汇总 1、启用客户机操作系统和远程控制台之间的复制和粘贴操作 解决方法：要在客户机操作系统和远程控制台之间进行复制和粘贴，必须使用vSphere Client 启用复制和粘贴操作。 步骤 a、使用vSphere Client 登录到vCenter Server 系统并选择虚拟机。 b、在摘要选项卡中，单击编辑设置。 c、选择选项> 高级> 常规，然后单击配置参数。 d、单击添加行，并在“名称”和“值”列中键入以下值。 名称值 isolation.tools.copy.disable false isolation.tools.paste.disable false 注意这些选项将替代在客户机操作系统的VMware Tools 控制面板中做出的任何设置。 e、单击确定以关闭“配置参数”对话框，然后再次单击确定以关闭“虚拟机属性”对话框。 f、重新启动虚拟机。 2、sco系统迁移过去之后找不到启动列表 解决方法：目前解决方法：使用软驱制作应急盘，通过应急盘来找到启动列表，如果不行的话，只能使用，现成的虚拟镜像导入vmware中，但是这种方法，要自己设置与自己相关的应用。 3、linux做迁移时手动添加的逻辑分区（LVM卷），迁移过去之后找不到这些分区 解决方法：：给虚拟机额外添加硬盘后融合，然后将数据重新拷入加入的硬盘中。 4、安装esxi的时候找不到万兆网卡 解决方法：解决方法：安装各个厂商OEM的esxi版本。 5、迁移时提示vss原卷不能克隆 解决方法：解决方法：查看是否有额外的设备插在服务器上，如usb设备。 6、Windows迁移之后，配置网卡的时候，会提示“IP已经被分配给其他的适配器” 解决方法：打开命令行窗口（运行cmd），输入： （1）、set DEVMGR_SHOW_NONPRESENT_DEVICES=1 （2）、devmgmt.msc 在弹出的“设备管理器”窗口。选择“查看（V）”—“显示隐藏的设备（W）”，然后展开“网络适配器”子项，可以看到一些透明图标显示的网卡信息，这些信息是源服务器的物理网卡信息。然后选择透明的设备卸载，RAS同步适配器为系统正常设备，不需要将其卸载。 7、Asianux3.0迁移之后不能显示图形化界面 解决方法：解决方法：cp /etc/X11/xorg.conf /etc/X11/xorg.conf.bak vi /etc/X11/xorg.conf 将xorg.conf文件中的selection “Devices”字段中Driver对应的值修改为“vmware”即可，修改完成后通过startx启动图形化界面。 虚拟机迁移技术漫谈 如何在虚拟机和物理机以及虚拟机和虚拟机之间的迁移系统 前言 系统的迁移是指把源主机上的操作系统和应用程序移动到目的主机，并且能够在目的主机上正常运行。在没有虚拟机的时代，物理机之间的迁移依靠的是系统备份和恢复技术。在源主机上实时备份操作系统和应用程序的状态，然后把存储介质连接到目标主机上，最后在目标主机上恢复系统。随着虚拟机技术的发展，系统的迁移更加灵活和多样化。 本系列文章全面介绍了虚拟机迁移的三种方式 P2V、V2V 和 V2P，及他们在内核虚拟机 KVM 上的实现方法，分成五个部分。第一部分，介绍虚拟机迁移的各种方法和相应的迁移工具，并且着重分析 Linux 平台上开源的虚拟化工具 KVM 和XEN 实时迁移中的的内存预拷贝技术； 第二部分介绍 KVM 虚拟机之间的 V2V 迁移技术，包括离线迁移和在线迁移；第三部分介绍基于 VMware 或 XEN 的虚拟机如何迁移到基于 KVM 的虚拟机；第四部分介绍物理机到虚拟机迁移 P2V 和虚拟机到物理机迁移 V2P 在 KVM 虚拟机上的实现；第五部分介绍和虚拟机迁移密切相关的虚拟机克隆、快照和备份技术。 回页首 虚拟机迁移简介 为什么要迁移服务器 迁移服务器可以为用户节省管理资金、维护费用和升级费用。以前的 x86 服务器，体积比较“庞大”；而现在的服务器，体积已经比以前小了许多，迁移技术使得用户可以用一台服务器来同时替代以前的许多台服务器，这样就节省了用户大量的机房空间。另外，虚拟机中的服务器有着统一的“虚拟硬件资源”，不像以前的服务器有着许多不同的硬件资源（如主板芯片组不同，网卡不同，硬盘，RAID 卡，显卡不同）。迁移后的服务器，不仅可以在一个统一的界面中进行管理，而且通过某些虚拟机软件，如 VMware 提供的高可用性工具，在这些服务器因为各种故障停机时，可以自动切换到网络中另外相同的虚拟服务器中，从而达到不中断业务的目的。总之，迁移的优势在于简化系统维护管理，提高系统负载均衡，增强系统错误容忍度和优化系统电源管理。 虚拟机迁移的性能指标 十个步骤将操作系统从物理机迁移到虚拟机 老板让你在很短的时间里执行一项操作系统迁移的任务，此时，如果你有一个功能完整的且经过测试的物理机到虚拟机迁移的解决方案，那么你将是一个真正的英雄！P2V的解决方案可以使你在不影响生产网络或不重新在生产网络中进行配置的前提下执行服务器迁移。在这里，我将向大家解释一些Microsoft Virtual Server Migration Toolkit（VSMT）的内部工作机制，并且演示一下为了实现迁移，应如何使用ADS来配置一台可移动的服务器。 在2006年12月份的“突破ADS障碍”一文中，我给大家展示了在Windows操作系统迁移时，如何构建一个基础的移动ADS解决方案。接着，在2007年5月份的文章“提升移动ADS解决方案”中，我展示了如何通过安装VSMT来扩展移动ADS解决方案，进而执行物理机到虚拟机的迁移。接下来我将给大家演示如何使用VSMT来执行一个P2V的迁移。 开始之前 通过本系列的文章，你已经知道如何在一个移动的小车上组合必要的硬件和安装基本的软件来创建一个移动的ADS解决方案：Windows Server 2003企业版，动态主机配置协议（DHCP）服务器、ADS1.1、Virtual Server 2005 R2 SP1和VSMT1.1。我们把资源服务器称为Testserver，并假想运行着Windows Server 2003企业版。为了执行一个P2V的迁移，你需要执行下面的十个步骤。 开始之前，我建议你花一些时间来看看你的服务器是否适合执行P2V转换。有时候，在一个不太稳定的生产服务器上执行一次P2V的迁移是不值得的。这是因为可能在迁移的过程中，那些不稳定的因素会出现。如果恰好出现这种情况，那么我建议你首先重建虚拟机，然后将数据从旧的物理服务器迁移到虚拟服务器中，这样做可能会更好一些。此外，对于那些带有OEM应用程序的服务器，在执行P2V迁移前，应该首先卸载或禁用这些应用程序，这样可以保证虚拟机在首次启动时，这些应用程序不会和虚拟机进行交互。 读到这里，先看看你的服务器适合进行P2V的转换吗？如果适合的话就让我们开始吧。 第一步：准备源系统 尽管VSMT不会修改源系统，我还是推荐你遵循一些最佳实践，在开始P2V迁移之前，首先对源操作系统进行备份。此外，禁用与物理服务器相关的所有驱动和应用程序，这些驱动和应用程序在虚拟机环境中将不再可用。 第二步：准备MobileP2V服务器 VSMT包括一个名为GatherHW.exe的工具，该工具能够在源服务器上收集物理硬件的信息，然后创建一个XML配置文件，你可以使用该配置文件来分析源系统中任何已知的硬件兼容性问题（动态磁盘、高于3.5GB的内存以及不支持的设备等等）。为了运行GatherHW.exe，你必须首先将它复制到源系统中。我推荐你首先在MobileP2V服务器上的VSMT安装目录（缺省为C:\Program Files\Microsoft VSMT）下创建一个名为VSMT的共享目录。当然，你还 虚拟机迁移技术简介 虚拟机迁移技术为服务器虚拟化提供了便捷的方法。目前流行的虚拟化工具如 VMware，Xen，HyperV，KVM都提供了各自的迁移组件。尽管商业的虚拟软件功能比较强大，但是开源虚拟机如 Linux 内核虚拟机 KVM 和 XEN 发展迅速，迁移技术日趋完善。本系列文章介绍了虚拟机迁移的三种方式 P2V、V2V 和 V2P，及他们在内核虚拟机 KVM 上的实现方法，分成五个部分。本文是第一部分，全面介绍了虚拟机迁移的各种方法和相应的迁移工具 , 并且着重分析了 Linux 平台上开源的虚拟化工具 KVM 和 XEN 实时迁移中的的内存预拷贝技术。 1.前言 系统的迁移是指把源主机上的操作系统和应用程序移动到目的主机，并且能够在目的主机上正常运行。在没有虚拟机的时代，物理机之间的迁移依靠的是系统备份和恢复技术。在源主机上实时备份操作系统和应用程序的状态，然后把存储介质连接到目标主机上，最后在目标主机上恢复系统。随着虚拟机技术的发展，系统的迁移更加灵活和多样化。 2.虚拟机迁移简介 2.1为什么要迁移服务器 迁移服务器可以为用户节省管理资金、维护费用和升级费用。以前的 x86 服务器，体积比较“庞大”；而现在的服务器，体积已经比以前小了许多，迁移技术使得用户可以用一台服务器来同时替代以前的许多台服务器，这样就节省了用户大量的机房空间。另外，虚拟机中的服务器有着统一的“虚拟硬件资源”，不像以前的服务器有着许多不同的硬件资源（如主板芯片组不同，网卡不同，硬盘，RAID 卡，显卡不同）。迁移后的服务器，不仅可以在一个统一的界面中进行管理，而且通过某些虚拟机软件，如 VMware 提供的高可用性工具，在这些服务器因为各种故障停机时，可以自动切换到网络中另外相同的虚拟服务器中，从而达到不中断业务的目的。总之，迁移的优势在于简化系统维护管理，提高系统负载均衡，增强系统错误容忍度和优化系统电源管理。 2.2虚拟机迁移的性能指标 一个优秀的迁移工具，目标是最小化整体迁移的时间和停机时间，并且将迁移对于被迁移主机上运行服务的性能造成的影响降至最低。当然，这几个因素互 实时迁移(live migration)是指在保证虚拟机上服务正常运行的同时，虚拟机在不同的物理主机之间进行迁移，其逻辑步骤与离线迁移几乎完全一致。不同的是，为了保证迁移过程中虚拟机服务的可用，迁移过程仅有非常短暂的停机时间。迁移的前面阶段，服务在源主机运行，当迁移进行到一定阶段，目的主机已经具备了运行系统的必须资源，经过一个非常短暂的切换，源主机将控制权转移到目的主机，服务在目的主机上继续运行。对于服务本身而言，由于切换的时间非常短暂，用户感觉不到服务的中断，因而迁移过程对用户是透明的。在线迁移适用于对服务可用性要求很高的场景。 01 live migration的概念 虚拟机实时迁移/动态迁移（Live Migration），作为系统虚拟化的一项关键技术，是将物理服务器上正在运行的一台或多台VM在线迁移到另一台物理服务器上。迁移过程中VM对外正常提供服务，整个迁移过程对VM用户透明。 02 live migration的概念 实时迁移的内容包括：虚拟机运行状态（CPU状态、内存镜像、设备状态、网络连接）及外存数据。 03 live migration的作用 负载均衡：将高负载物理服务器上的虚拟机动态迁移到低负载的物理服务器上，保证数据中心资源合理分配。 在线维护：在对物理服务器进行维护前，实时将上面运行的虚拟机迁移到其他服务器上，不会因设备维护导致服务中断。 能源管理：将多个利用率不高的物理服务器上的虚拟机在线整合到少量几台物理服务器上，降低能耗。 04 live migration的分类 按照虚拟机存储的迁移需求可划分为基于共享存储的实时迁移和全系统实时迁移。 ●基于共享存储的实时迁移：物理服务器之间采用SAN或NAS之类的集中式共享外存 设备，因而在迁移时只需要进行虚拟机运行状态的迁移。 ●全系统迁移：物理服务器之间没有采用共享外存设备，外存数据保存在物理服务器本地； 或者需要将虚拟机迁移到另一个数据中心。实时迁移中既要迁移运行状态，又要迁移存储数据。 按照虚拟机迁移的网络环境可划分为基于LAN的实时迁移和基于WAN的实时迁移。 ●基于LAN的实时迁移：迁移范围在一个数据中心的二层网络内，能够保证数据传输速 率。 ●基于WAN的实时迁移：迁移范围在两个数据中心间的WAN链路上，网络传输带宽受 限。 按照虚拟机迁移的规模可划分为单虚拟机实时迁移和虚拟机集实时迁移。 ●单虚拟机实时迁移：一个迁移过程中只迁移独立的一个虚拟机。 ●虚拟机集实时迁移：一个迁移过程中同时迁移多台虚拟机，且这些虚拟机可能是完成同 一任务的一个集群。 05 live migration算法 三种基本算法：Pre-copy（主流、学术、商用）；Post-copy（学术）；基于日志系统的迁移（学术） Pre-copy核心机制：迁移开始之后，源主机VM仍在运行，目的主机VM尚未启动。迁移通过一个循环，将源主机VM的内存数据发送至目的主机VM。循环第一轮发送所有的内存页数据，接下来的每一轮循环发送上一轮预拷贝过程中被VM写过的脏页内存dirty pages。 vmware 常见问题 Vmware vSphere常见问题及解决办法 Advertisement 故障状态： 启动虚拟机时95%,停顿并且进程中断,提示：ubable to access files since it is locked。 祸根：HA 解决方法： （1）首先将cluster中的HA功能关闭。如果该功能不关闭，容易造成死锁,，VM不断跳动,，不断再不同的ESX内循环被锁，徒劳而无功。 （2）磁盘文件被锁，要解决，必须要知道到底是哪台ESX把他给锁住了，这是关键。 方法：看/var/log/vmkernel但是，在做这些前, 再准备些别的工作。 （3）在VC中，把被锁的VM从Inventory中remove掉。原因很简单，这是一个unregister的过程。 （4）根据/var/log/vmkernel，搜索owner，可以找到类似以下的语句: Oct 19 04:23:33 esx-hostname vmkernel: 3:06:29:47.992 cpu6:1656)FS3: 1975: Checking if lock holders are live for lock [type 10c00001 offset 52008960 v 380, hb offset 3554304 Oct 19 04:23:33 esx-hostname vmkernel: gen 17, mode 1, owner 48f5f637-462688bc-fd28-0e1a6434b6f8 mtime 38112] OK，owner后面的48f5f637-462688bc-fd28-0e1a6434b6f8就是你的target了。因为他就是锁住VM 的宿主.。 老板让你在很短的时间里执行一项操作系统迁移的任务，此时，如果你有一个功能完整的且经过测试的物理机到虚拟机迁移的解决方案，那么你将是一个真正的英雄！P2V的解决方案可以使你在不影响生产网络或不重新在生产网络中进行配置的前提下执行服务器迁移。在这里，我将向大家解释一些Microsoft Virtual Server Migration Toolkit（VSMT）的内部工作机制，并且演示一下为了实现迁移，应如何使用ADS来配置一台可移动的服务器。 在2006年12月份的“突破ADS障碍”一文中，我给大家展示了在Windows操作系统迁移时，如何构建一个基础的移动ADS解决方案。接着，在2007年5月份的文章“提升移动ADS解决方案”中，我展示了如何通过安装VSMT来扩展移动ADS解决方案，进而执行物理机到虚拟机的迁移。接下来我将给大家演示如何使用VSMT来执行一个P2V的迁移。 开始之前 通过本系列的文章，你已经知道如何在一个移动的小车上组合必要的硬件和安装基本的软件来创建一个移动的ADS解决方案：Windows Server 2003企业版，动态主机配置协议（DHCP）服务器、ADS1.1、Virtual Server 2005 R2 SP1和VSMT1.1。我们把资源服务器称为Testserver，并假想运行着Windows Server 2003企业版。为了执行一个P2V的迁移，你需要执行下面的十个步骤。 开始之前，我建议你花一些时间来看看你的服务器是否适合执行P2V转换。有时候，在一个不太稳定的生产服务器上执行一次P2V的迁移是不值得的。这是因为可能在迁移的过程中，那些不稳定的因素会出现。如果恰好出现这种情况，那么我建议你首先重建虚拟机，然后将数据从旧的物理服务器迁移到虚拟服务器中，这样做可能会更好一些。此外，对于那些带有OEM应用程序的服务器，在执行P2V迁移前，应该首先卸载或禁用这些应用程序，这样可以保证虚拟机在首次启动时，这些应用程序不会和虚拟机进行交互。 读到这里，先看看你的服务器适合进行P2V的转换吗？如果适合的话就让我们开始吧。 第一步：准备源系统 目录 摘要……………………………………………………．．１ＡＢＳＴＩｉＡＣＴ………一…………………………………………．３符号说明……………………………………………………５第１章绪论…………………………………………………７１．１选题背景及意义…．｝…………．．：…．！………．．…．．．．．｛．．…．７１．２国内外研究现状…．｛……．…：……．．：………………．……８１．２．１云计算研究现状……………叫………………．……８ １．２．２虚拟化及动态迁移研究现状……．。………………．…．’．１０１．３本文主要工作及创新点…………………………………．．１１：１．３．１主要工作…．：………………．１………………．！……１１ １．３．２创新点…………………………………．………１１１．４论文结构安排．．…………………．………．……………１２１．５本章小节．…………………．………………………．…１３第２章系统相关技术………………………………．．………。１４２．１云计算简介……………………………………………１４２．１．１云计算分类………………………………………１４２．１．２云计算的服务模式……………………．．：……。．…．．１４２．１．３云计算的特点……………………………………．１６２．２虚拟化相关技术……．…．……………………………．．．１６２．２．１ＶＭＭ模型．…………．……………………………．１７ ２．２．２常见虚拟化解决方案及其相关技术……………………．１８ ２．２．３ＫＶＭ基本工作原理……．…．………．……．……．…．．２３ ｆ。 ２．３虚拟机的动态迁移………．．．…．：………………ｌ………２４２．３．１动态迁移策略…………………………………．…２４２．３．２动态迁移的评价指标…………．……．．．……………２５ ２．３．４动态迁移分类………………………．…．…．．：……２５ ２９卷 第４期２０１２年４月 微电子学与计算机 ＭＩＣＲＯＥＬＥＣＴＲＯＮＩＣＳ ＆ＣＯＭＰＵＴＥＲ Ｖｏｌ．２９ Ｎｏ．４ Ａｐ ｒｉｌ ２０１２收稿日期：２０１１－０６－１０；修回日期：２０１１－０８－１５ 云环境下基于虚拟机动态迁移的调度策略研究 方义秋１，唐道红１，葛君伟２ （１重庆邮电大学计算机科学与技术学院，重庆４０００６５；２重庆邮电大学图书馆，重庆４０００６５ ）摘 要：针对目前云环境资源调度采用静态负载均衡策略易于导致资源浪费的问题，提出了一种双限定值的虚拟机动态迁移的调度策略． 该策略将当前负载状况与负载过重或过轻时两个限定值比较，选择介于二者之间能耗较低的虚拟机迁移至目标节点．仿真实验表明，该策略能够减少迁移次数，降低虚拟机迁移能耗，从而尽可能达到负载均衡和满足服务等级协议的需求． 关键词：云计算；虚拟机动态迁移；资源调度；减少能耗；负载均衡；服务等级协议 中图分类号：ＴＰ３１１ 文献标识码：Ａ 文章编号：１０００－７１８０（２０１２）０４－００４５－０４ Ｒｅｓｅａｒｃｈ ｏｎ Ｓｃｈｅｄｕｌｅ Ｓｔｒａｔｅｇｙ Ｂａｓｅｄ ｏｎ Ｄｙｎａｍｉｃ Ｍｉｇｒａｔｉｏｎ ｏｆＶｉｒｔｕａｌ Ｍａｃｈｉｎｅｓ ｉｎ Ｃｌｏｕｄ ＥｎｖｉｒｏｎｍｅｎｔＦＡＮＧ Ｙｉ－ｑｉｕ１，ＴＡＮＧ Ｄａｏ－ｈｏｎｇ１，Ｇ Ｅ Ｊｕｎ－ｗｅｉ ２ （１Ｃｏｌｌｅｇｅ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ ａｎｄ Ｔｅｃｈｎｏｌｏｇｙ，Ｃｈｏｎｇｑｉｎｇ Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｐｏｓｔｓ ａｎｄ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｈｏｎｇｑｉｎｇ ４０００６５，Ｃｈｉｎａ；２Ｌｉｂｒａｒｙ，Ｃｈｏｎｇｑｉｎｇ Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｐｏｓｔｓ ＆Ｔｅｌｅｃｏｍ，Ｃｈｏｎｇｑｉｎｇ ４０００６５，Ｃｈｉｎａ）Ａｂｓｔｒａｃｔ：Ａｍｉｎｇ ａｔ ｔｈｅ ｃｕｒｒｅｎｔ ｒｅｓｏｕｒｃｅ ｓｃｈｅｄｕｌｉｎｇ ｕｓｉｎｇ ｔｈｅ ｓｔａｔｉｃ ｌｏａｄ ｂａｌａｎｃｉｎｇ ｓｔｒａｔｅｇｙ ｉｎ ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇｅｎｖｉｒｏｎｍｅｎｔ ｃｏｕｌｄ ｅａｓｉｌｙ ｌｅａｄ ｔｏ ｔｈｅ ｗａｓｔｅ ｏｆ ｒｅｓｏｕｒｃｅｓ，ｔｈｅ ｐａｐｅｒ ｐｒｅｓｅｎｔｓ ｔｈｅ Ｄｏｕｂｌｅ Ｔｈｒｅｓｈｏｌｄ（ＤＴ）ｏｆ ｓｃｈｅｄｕｌｉｎｇｓｔｒａｔｅｇｙ ｂａｓｅｄ ｏｎ ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ ｌｉｖｅ ｍｉｇｒａｔｉｏｎ．Ｔｈｅ ｓｔｒａｔｅｇｙ ｗｉｌｌ ｃｏｍｐａｒｅ ｔｈｅ ｃｕｒｒｅｎｔ ｌｏａｄ ｃｏｎｄｉｔｉｏｎｓ ｗｉｔｈ ｄｏｕｂｌｅｔｈｒｅｓｈｏｌｄ ｖａｌｕｅｓ ｉｎ ｗｈｉｃｈ ｉｓ ｏｖｅｒｌｏａｄｉｎｇ ｏｒ ｔｏｏ ｌｉｇｈｔ ｌｏａｄｉｎｇ，ａｎｄ ｃｈｏｏｓｅ ｔｈｅ ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ ｗｉｔｈ ｌｏｗｅｒ ｅｎｅｒｇｙｃｏｎｓｕｍｐｔｉｏｎ ａｎｄ ｂｅｔｗｅｅｎ ｗｉｔｈ ｔｈｅ ｔｗｏ ｖａｌｕｅｓ ｔｏ ｍｉｇｒａｔｅ ｔｈｅ ｄｅｓｔｉｎａｔｉｏｎ ｎｏｄｅ．Ｅｘｐｅｒｉｍｅｎｔａｌ ｒｅｓｕｌｔｓ ｓｈｏｗ ｔｈａｔ ｔｈｅｓｔｒａｔｅｇｙ ｃａｎ ｒｅｄｕｃｅ ｔｈｅ ｍｉｇｒａｔｉｏｎ ｔｉｍｅｓ ａｎｄ ｔｈｅ ｅｎｅｒｇｙ ｃｏｎｓｕｍｐｔｉｏｎ ｏｆ ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ ｍｉｇｒａｔｉｏｎ，ｓｏ ａｓ ｔｏ ａｃｈｉｅｖｅｌｏａｄ ｂａｌａｎｃｉｎｇ ａｎｄ ｍｅｅｔ ｓｅｒｖｉｃｅ ｌｅｖｅｌ ａｇｒｅｅｍｅｎｔ（ＳＬＡ）ｒｅｑｕｉｒｅｍｅｎｔｓ．Ｋｅｙ ｗｏｒｄｓ：ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ；ｄｙｎａｍｉｃ ｍｉｇｒａｔｉｏｎ ｏｆ ｖｉｒｔｕａｌ ｍａｃｈｉｎｅｓ；ｒｅｓｏｕｒｃｅ ｓｃｈｅｄｕｌｉｎｇ；ｒｅｄｕｃｉｎｇ ｅｎｅｒｇｙ；ｌｏａｄｂａｌａｎｃｉｎｇ ；Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ（ＳＬＡ）１ 引言 云计算的一个很重要的特点就是资源虚拟 化［１］ ．通过互联网将这些动态的可扩展的资源连接起来整合成云计算的庞大的计算和存储规模［２］ ，由 于云中资源的异构性和用户需求的动态性，如果不能合理地调度资源， 势必会导致资源的浪费或者负载过重问题．尽管解决系统负载的方法包括：目标地址散列调度、加权轮叫调度算法等，但是往往都采用静态的负载均衡策略，很难适应用户请求的动态变化． 由于计算资源需求在不断增加，总体的能源消耗也将持续增长，资源池中基础设施资源的高能耗导致资源利用率较低和资源管理成本加大．为了减少高电力能耗所带来的巨大代价，云计算平台利用虚拟化技术构建的虚拟集群，能够动态地组织异构 的计算资源［３］ ，不仅可以提供有效和安全的计算和 存储资源，还可以根据系统的负载变化将虚拟机重新映射到合适的物理主机上，有效地将资源整合并充分利用，从而减少使用的硬件资源的数量和提高资源利用率．这个虚拟机重新映射过程可以借助虚拟机的动态迁移来实现． 一、迁移虚拟机 迁移是指将虚拟机从一个主机或存储位置移至另一个主机或存储位置的过程。复制虚拟机是指创建新的虚拟机，并不是迁移形式。 在 vCenter Server 中，有以下迁移选项： 冷迁移：将已关闭电源的虚拟机移至新的主机。（可选）可以将配置文件和磁盘文件重新定位到新的存储位置。可以使用冷迁移将虚拟机从一个数据中心移至另一个数据中心。 迁移已挂起的虚拟机：将已挂起的虚拟机移至新的主机。（可选）可以将配置文件和磁盘文件重新定位到新的存储位置。可以将已挂起的虚拟机从一个数据中心迁移至另一个数据中心。 通过vMotion 迁移：将已打开电源的虚拟机移至新的主机。通过 vMotion 迁移， 可以在不中断虚拟机可用性的情况下将虚拟机移至新的主机，但无法使用 vMotion 将虚拟机从一个数据中心移至另一个数据中心。 通过Storage vMotion 迁移：将已打开电源的虚拟机的虚拟磁盘或配置文件移动到新数据存储。通过 StoragevMotion 迁移，可以在不中断虚拟机可用性的情况下，移动虚拟机的存储器。已挂起虚拟机的迁移以及通过 vMotion 迁移有时也称为“热迁移”，因为它们允许在不关闭虚拟机电源的情况下迁移虚拟机。通过 vMotion 迁移有时也称为“实时迁移”。可以手动移动虚拟机，也可以设置已调度任务来执行冷迁移。通过克隆虚拟机或复制其磁盘和配置文件可以创建新的虚拟机，克隆并不是迁移的一种形式。 冷迁移 冷迁移是对已关闭电源的虚拟机进行迁移。通过冷迁移，您可以选择将关联的磁盘从一个数据存储移动到另一个数据存储。虚拟机不需要位于共享存储器上。 在开始冷迁移过程前，必须关闭要迁移的虚拟机的电源。 如果将虚拟机配置为具有 64 位客户机操作系统，则尝试将其迁移到不支持 64 位操作系统的主机时，vCenter Server 会生成警告。冷迁移虚拟机时，不会应用 CPU 兼容性检查。 冷迁移包含以下任务：1 如果选择了移动到一个不同的数据存储的选项，则会将配置文件（包括 NVRAM 文件（BIOS 设置））和日志文件从源主机移至目标主机的关联存储区域中。如果选择了移动虚拟机的磁盘，则也会移动这些磁盘。 2 向新主机注册虚拟机。 3 如果选择了移动到一个不同的数据存储的选项，则在迁移完成后，会将旧版本的虚拟机从源主机中删除。 迁移已挂起的虚拟机 通过迁移已挂起的虚拟机，也可以选择将关联的磁盘从一个数据存储移至另一个数据存储。虚拟机不需要位于共享存储器上。 在VMware esxi虚拟机中系统克隆及迁移的方法 免费的VMWare ESXi非常强大，于是在vSphere5.0平台中ESXi取代了ESX，不过貌似不再是免费使用了，因为我在VM ware官网只能下载到免费评估版的ESXi，具体怎么个评估我还没体会，哪位朋友知道请告知我。 使用ESXi经常会遇到这样的问题，我需要建立多个虚拟机，都是windows2003操作系统，难道必须一个一个安装吗？VMware ESXi、VMware vCenter Server 和vSphere Client，它们分别是vSphere 的虚拟化层、管理层和接口层。作为接口层的vSphere Client客户端并不提供克隆虚拟机的功能，需要安装vCenter管理ESXi才有这一功能。 虽然如此，但是我们可以以手动的方式完成这项工作。 下面是克隆“win2003”这台虚拟机的操作过程： 1、进入vSphere client，关闭需要克隆的虚拟机win2003 2、选中ESXi服务器主机，在右侧点击“配置”选项卡，选择存储器，右侧的存储器名称上点右键，选择“浏览数据存储” 3、新建文件夹kelong，进入win2003文件夹，把win2003.vmx和win2003.vmdk这两个文件复制到文件夹kelong下，复制过程非常快，不到一分钟。 4、在win2003.vmx文件上点右键，选择“添加到清单”，弹出提示，询问这个虚拟机是移动的还是复制的，选择“I coyied i t”，确定。 5、开始建立虚拟机的向导，最后弹出提示“无法打开磁盘或其所依赖的快照磁盘之一”，这是因为虚拟机之前做过快照，所以需要把win2003-000003.vmdk文件也复制过来。 6、把win2003-000003.vmdk文件复制过来再执行“添加到清单”，克隆完成。克隆出来的虚拟机与源虚拟机环境配置完全相同，包括IP地址、用户名口令等，需要手动更改。 这是在同一台ESXi服务器下做的克隆操作，如果是不同的ESXi服务器之间做克隆操作呢？那么就需要把文件复制到不同的E SXi服务器。在网上搜了一下，复制的方法有说用移动存储设备，有说用FTP，但是我觉得用SCP命令最方便。下面是我的迁移操作过程： 1、SSH登到ESXi服务器上，首先需要找到源虚拟机文件，路径很奇怪，可以用df -h查看一下文件系统及空间占用的情况。 找到文件系统名为vmfs3的挂载路径，或者以空间占用的情况来判断虚拟机文件存放的路径应该是/vmfs/volumes/4f4f4f9 4-9c9152ca-c226-842b2b1419f1 2、在这个路径下找到win2003.vmx和win2003.vmdk这两个文件，执行scp命令将文件复制到目标服务器的相应目录下，这个过程比较漫长，我用了大概2小时左右，当然如果是做过快照的虚拟机还需要复制快照文件， 3、然后在vSphere client中执行“添加到清单”就可以了。虚拟机迁移技术漫谈,第 2 部分
将实体机迁移到VMware虚拟机
11虚拟机迁移
云计算中虚拟机实时迁移技术的鲁棒性研究
数据的迁移服务V200R100C00----VMware虚拟机数据的迁移方案设计
Vmware vSphere常见问题汇总
虚拟机迁移技术漫谈
将操作系统从物理机迁移到虚拟机
虚拟机迁移方法简介
虚拟机实时迁移
vmware常见问题
十个步骤将操作系统从物理机迁移到虚拟机
基于KVM虚拟机动态迁移的研究与实现
云环境下基于虚拟机动态迁移的调度策略研究
虚拟机迁移及虚拟化优化HA配置
在VMware esxi虚拟机,系统克隆,迁移的方法
相关主题
文本预览