当前位置:首页 >> 计算机硬件及网络 >>

Hyper-V热迁移vs vMotion虚拟机迁移指南


Hyper-V 热迁移 vs. vMotion: 虚拟机迁移指南

Hyper-V 热迁移 vs. vMotion:虚拟机迁移指南
VMware 首次在 2003 年在 GSX 和 vCenter 中引入 vMotion 时,无疑在业内投下了一颗重磅炸弹。从此 进入了虚拟机热迁移时代。为了追赶 VMware 的脚步,微软在 Windows Server 2008 Hyper-V 中首次引入 了 Live Migration(热迁移)功能,取代了之前的 Quick Migration。 VMware 和微软现在提供相似的虚拟机热迁移功能:允许 IT 专业人员将运行中的虚拟机从一台主机迁移 到另一台主机,不再需要暂停时间。 尽管两大供应商各自提供的虚拟机热迁移功能都很重要,但两者在过程上仍存在一些差异。在本期技术手 册中,我们将展示如何使用两种热迁移特性,并解释 Hyper-V Live Migration 和 vMotion 之间的差异。

了解 VMware vMotion
VMware vSphere vMotion 将运行中的虚拟机从一个 ESX/ESXi 主机迁移到另一个, 无需停止虚拟机的操 作。但 vMotion 有一些限制。

?vSphere vMotion 能够同时迁移多少台虚拟机? ?五个被忽视的 vSphere 5 特性 ?利用 Metro vMotion 构建完美基础设施需要满足的需求 ?SSD 解决数据中心存储瓶颈问题 ?解读 vSphere 5.1 VMotion 增强功能 VMware vMotion 技巧
VMware vSphere vMotion 使用分布式资源调度程序(DRS)平衡主机利用率和支持维修计划。来看看 VMware vMotion 更多常见技巧。

?虚拟机可用性技术纵览:VMware HA vs. FT 和 VADP vs. SRM ?通过 vSphere DRS 提升主机效率
2 / 50

?部署 VMware vCenter SRM 时的三大注意事项 ?VSphere Metro Storage Cluster:可在一个集群中实现跨站点 HA 和 DRS 了解 Hyper-V 热迁移
Hyper-V 热迁移是 vMotion 的竞争产物。事实上,最新的版本对一些 VMware 用户产生了深刻的影响。 但是,有一些重要的区别你应该知道。

?对比 vMotion 与动态迁移之间的细微差异 ?Hyper-V 动态迁移原理详解 ?使用 SCVMM PowerShell cmdlets 自定义 Hyper-V 热迁移 Hyper-V 热迁移技巧
兼容性问题或资源限制可以打断 Hyper-V 热迁移。这里有一些提示和技巧可帮助你更好地利用 Hyper-V 热迁移。

?Hyper-V 动态迁移失败的常见原因 ?使用 PowerShell 克服 Hyper-V 热迁移限制 ?Hyper-V 热迁移相关项:brownout、blackout 与 dirty 页面

3 / 50

vSphere vMotion 能够同时迁移多少台虚拟机?

vSphere 引入了 VMware vMotion 虚拟机在线迁移技术。随着 vSphere 的不断发展,vMotion 也在不 断成长——迁移速度更快,功能更加强大——但这并不意味着不存在限制。 在设计 vSphere 基础设施时,我需要考虑 vMotion 的哪些限制? 让我们先从底层的基础设施说起。VMware vSphere 是运行在 x86 服务器上的虚拟化管理平台。然而, vSphere vMotion 只能在处理器彼此兼容的服务器之间迁移虚拟机。你可以使用 vMotion 增强功能以使新旧 服务器处理器处理相同的指令集,但是 vMotion 无法将虚拟机从使用 Intel CPU 的服务器迁移至使用 AMD CPU 的服务器。 网络配置同样对 VMotion 的成败起着重要作用。VMware 在 vSphere 5.1 中增强了网络监控以及优化功 能,例如在 vSphere 5.1 中管理员能够更加轻松地解决由于交换机配置不正确所引发的网络问题,这为确保网 络符合 vMotion 的要求提供了帮助。 vSphere vMotion 只能在网络延迟低于 5ms 的环境中使用。 如果认为网 络延迟需求过于严格,管理员可以使用 vSphere 企业增强版所提供的网络延迟感知域 vMotion 功能,该功能 将可接受的网络延迟限制减少为原来的一半,为 10ms。 与旧有的版本不同,现在 vMotion 可以使用多块物理网卡来迁移虚拟机。从 vSphere 5 开始,vMotion 能够使用多达 4 块 10GB 的物理网卡或者 16 块 1GB 的物理网卡。 虚拟机 vMotion 能够在使用不同存储的主机之间迁移吗? 在 vSphere 5.1 之前 ,vMotion 一直存在的一个限制就是共享存储。非共享在线迁移允许虚拟机在不同 主机之间不受直连存储限制就能够进行在线迁移。既然 vMotion 同时提供了内存以及存储迁移,那么只要网 络支持,虚拟机就能够在 vCenter Server 实例之间进行迁移。 在不同磁盘阵列之间迁移数据的 Storage vMotion 技术也在不断发展。在 vSphere 5.1 之前,Storage vMotion 需要使用共享存储—主机需要能够访问所有的数据存储。现在, Storage vMotion 和 vMotion 能够 一起使用,将虚拟机的内存以及数据迁移到新主机面临的限制越来越少。

4 / 50

VMware 管理员必须关注 vMotion 哪些限制? VMware vMotion 将能够同时迁移的虚拟机的数量限制为 8 台。相对于 vSphere vMotion 4.0 以及之前 的版本只能同时迁移一台虚拟机,这是一个巨大的提高。但是由于 vSphere vMotion 的主要竞争对手,微软 的 Hyper-V 的在线迁移不限制同时迁移的虚拟机的数量, 因此 VMware vMotion 存在的限制已经受到了批评。 使用 vSphere 5.1 以及 1Gb 的网络连接, 每台主机最多能够同时迁移四台虚拟机。 如果基础设施使用 10Gb 的网络连接,那么每台主机最多能够同时迁移八台虚拟机。

(来源:TechTarget 中国 作者:Meredith Courtemanche 译者:张冀川)

5 / 50

五个被忽视的 vSphere 5 特性

Storage DRS 以及可扩展性的增强占据了 vSphere 5 报道的头条,但实际上 VMware vSphere 5 一些几 乎不为人知的特性可能会对你的基础设施产生更大的影响。 vSphere 的每次发布都和圣诞节有相似之处:我们迫不及待地打开我们的礼物,查看里面究竟装了什么。 在好奇心过后,我注意到 vSphere 5 一些从未讨论过的新特性及增强功能可能将会改变我们设计与管理 VMware 基础设施的方式。 让我们一起来看一下新 VMFS(虚拟机文件系统)、重新设计的 Storage vMotion 以及 vSphere 5 的其 他一些几乎不为人知的特性及增强功能。 VMFS 5 使用 VMFS 5 能够创建 2TB 的虚拟磁盘,但是创建新的 VMFS 卷只能使用 1MB 的块大小。多年以来, VMware 管理员必须处理各种各样的块大小并限制虚拟磁盘大小;而 VMFS 5 解决了大量相关的问题。 从 VMFS 3 升级至 VMFS 5 很简单,而且不会对数据造成破坏(在以前,如果从之前版本的 VMFS 升级, 将破坏数据卷上的所有数据包括虚拟机),而且升级至 VMFS 5 同样可以保留之前配置的块大小。 虽然 VMFS 5 支持更大的块大小,但是特定的 vStorage API 特性要求数据存储具有相同的块大小。其中一 个特性就是复制-卸载(copy-offload),该特性在 hypervisor 和阵列上卸载与存储相关的特定功能。因此如 果你的 VMFS 3 没有使用 1MB 的块大小,那么最好创建新的 VMFS 5 数据卷。 VMFS 5 同样与通过多个 LUN 组合而成的容量高达 64TB 的 LUN 兼容。 SplitRx 模式 vSphere 5 很有趣的网络特性之一就是 SplitRx,该特性是接收、处理从其他网络设备发送到网卡的数据 包的新方法。

6 / 50

在以前,虚拟机在单个共享的环境中处理网络数据包,这个过程可能会受到抑制。现在能够将接收到的数 据包拆分到多个独立的环境中进行处理(想象一下,以前数据包必须在一个通道上等待,但是现在有了一条专 用的 VIP 通道直接访问虚拟机)。 使用 SplitRx 模式,你可以指定哪块虚拟网卡在单独的环境中处理网络数据包。但是你只能在使用 VMXNET3 适配器的虚拟网卡上启用 SplitRx 模式。 但是 vSphere 5 的这一特性同样增加了主机的 CPU 开销,因此在部署时需要引起注意。VMware 建议在 多播工作负载下也就是同时具有多个网络连接时使用 SplitRx 模式。 网络 I/O 控制 在 vSphere 5 中 VMware 同样增强了网络 I/O 控制,这样你可以划分虚拟机流量的优先级。VMware 在 vSphere 4 中引入了网络 I/O 控制,允许创建资源池并为主机特定的网络流量,比如 NFS、iSCSI、管理控制 台以及 vMotion 设置优先级。但是虚拟机的所有流量都是在一个资源池中,因此你不能为单个虚拟机的网络 流量设置优先级,确保关键的工作负载能够使用足够的网络带宽。 然而,在 vSphere 5 中这个问题得到了解决。新的资源池基于 802.1p 网络标记。现在你可以创建多个资 源池,为运行在一台主机上多个虚拟机分配不同的网络带宽。这一特性对于多租户环境或者在主机上混合了关 键应用及非关键应用的情况下非常有意义,能够确保重要的虚拟机获得足够的网络资源。 Storage vMotion 功能增强 vSphere 5 重新设计了 Storage vMotion,使其更有效率。在 Storage vMotion 过程中,vSphere 5 不 再使用变化块追踪(Change Block Tracking)记录磁盘的变化。相反,Storage vMotion 执行镜像写操作, 这意味着在迁移过程中所有写入操作都同时写入到源磁盘和目标磁盘。为确保两端的磁盘保持同步,源和目标 磁盘同时对每次写入操作进行确认。 VMware 同时对 Storage vMotion 进行了另一个巨大的改进:现在你可以在线迁移具有活动快照的虚拟 机,这在 vSphere 4 中是不允许的。这是个很大的改进,因为 Storage vMotion 操作将在 vSphere 5 更加变 得通用。而且新的存储分布式资源调度特性将定期在数据存储之间迁移虚拟机,重新分布存储 I/O 负载。 vMotion 功能增强

7 / 50

vSphere 5 的很多特性都依赖 vMotion 这一核心技术,VMware 在 vSphere5 中增强了 vMotion 的性能 以及可用性。 也许最大改进就是执行 vMotion 操作时能够使用多块物理网卡。 现在 VMkernel 将使用分配给 VMkernel 端口组的所有物理网卡自动对 vMotion 流量进行负载均衡。现在 vMotion 能够使用多达 16 块的 1GB 物理网 卡或者多达 4 块的 10GB 物理网卡,这将大大加快迁移速度。 由于引入了城域 vMotion(Metro vMotion),vMotion 将能够更好地进行扩展。Metro vMotion 将 VMkernel 接口与主机之间可接受的往返延迟增加到了 10 毫秒,而在调整之前,所支持的最大延迟仅为 5 毫 秒,这在快速局域网中限制了 vMotion 的可用性。 Metro vMotion 在主机之间仍然需要快速,低延迟的网络连接,但是它允许在更远的距离之间比如城域 网中使用 vMotion。在城域网中,主机通常位于不同的物理区域。 由于在城域网中不同站点之间的距离通常少于 100 英里,所以网络延迟足以支持 vMotion。但是跨越更 远距离的网络通常会产生更多的网络延迟,所以仍不能使用 vMotion 进行迁移。

(来源:TechTarget 中国 作者:Eric Siebert 译者:张冀川)

8 / 50

利用 Metro vMotion 构建完美基础设施需要满足的需求

这是虚拟化管理员的一个梦想:在没有宕机时间的情况下将一台运行中的虚拟机从一个数据中心迁移到另 一个当中。这个梦想意味着需要构建一套完美的基础设施来支撑 VMware Metro vMotion 特性——这可不是 一个小任务。 VMware Metro vMotion 可以在两个单独的物理数据中心之间移动虚拟机,而且不需要将服务器处于离 线状态。Metro vMotion 还允许 VMware vSphere 高可用性(HA)特性在一个数据中心发生灾难时,在其 他数据中心重起所有的虚拟机。 但是实现 Metro vMotion 的四个主要需求已经超过了传统的 IT 部门中的网络、 vCenter 和存储相关定义了。 Metro vMotion 的两个网络需求 VMware 需要 Metro vMotion 用户在两个数据中心间扩展 2 层网络, 以使得相同的 IP 可以在两个站点当 中同时存在。满足这样的需求之后,当虚拟机在站点之间进行 vMotion 迁移时,其中的网络配置,特别是 IP 地址,就不会发生改变了。这必须是一个单独的子网段,而仅仅是同样的 IP 地址范围,否则在操作完成之后, 第一个站点会断开到进行迁移的虚拟机的网络连接。HA 和 vMotion 不能更改虚拟机的网络配置,因为它们是 vSphere 的特性。在两个数据中心里使用同样的网段允许虚拟机在进行 vMotions 迁移之后仍然可以保持网络 连接。 所有主机上的全部 Metro vMotion 连接必须位于同样的 IP 地址段上。所有主机上的全部 ESXi 管理端口 也必须位于同一个 IP 地址段,但是通常情况下,它们和 vMotion 也会位于不同的网段,不管是在哪个站点。 如果你想要在两个数据中心的两个网段间进行通讯,需要确保两个站点之间的往返延迟要小于 10 毫秒, 冗余带宽至少需要 622Mbps。 使用单个 vCenter 进行管理 Metro vMotion 使用的所有 vSphere 主机服务器只能由一个 vCenter 实例进行管理。Metro vMotion 不能穿越 vCenter 数据中心对象的界限,所以如果所有的主机没有位于一个 vCenter 数据中心对象, 虚拟机将

9 / 50

不知如何进行操作。在不同数据中心间使用 VMware HA 时,所有的主机共享同一个 vCenter 集群对象,因为 这是一个 HA 的管理域。 使用 VMware 分布式资源调度工具中 affinity rule 来控制虚拟机主要存在与数据中心当中, 哪些虚拟机必 须位于同一个数据中心。比如,为了减少站点间的流量,可以为一个三层应用程序中的 Web、app 和数据库 服务器配置 affinity rule,而这个服务器组也拥有 affinity rule,以确定在哪个数据中心以及之间的关系。这个 配置同样需要所有的主机都位于相同的 vCenter 集群对象当中。 主动存储障碍 最后也是最困难的部分是,Metro vMotion 需要两个站点中的存储阵列都是处于主动模式的。这需要在 5 毫秒的延迟内完成同步复制。在 vSphere 看来,这对存储应该是一个存储阵列,还必须同时提供同样的逻辑设 备编号(LUN)读写版本。为了实现这个真正的主动存储阵列对,每次写操作必须在告知主机之前在两个阵列 上完成。 大多数存储无法在两个站点中的不同阵列间提供这种级别的一致性。在设计这部分时,会在很大程度上会 限制基础设施的可用性。

(来源:TechTarget 中国 作者:Brian Knudtson 译者:王学强)

10 / 50

SSD 解决数据中心存储瓶颈问题

存储是现代数据中心一个重要的资源。存储瓶颈可能使关键应用程序运行缓慢影响用户体验。存储支持应 用、虚拟机、数据保护、用户数据和其他企业重要的任务,总是需求更多的卷。 TechTarget 采访了存储行业专家 Dennis Martin,请他谈谈存储在数据中心瓶颈的一些看法。 今天您在哪里看到数据中心正在发生存储瓶颈?比如,我们的网络交换机或存储阵列本身具有最大的问题 是什么?是太苛刻的应用程序还是其他关键问题? Martin 解释说问题根源似乎在存储阵列本身。 “我目前看到最大的瓶颈是存储末端,那就是机电硬盘已经 达到性能极限,”他说,“这些都是在原本电子环境下的机电设备。” 考虑到一个虚拟环境,像 VMotion 或 VMware DRS 工具可以将虚拟机(VM)从一个服务器到另一个服 务器中心平衡工作负载。但问题是,迁移过程中需要将虚拟机移动到存储,其中控制器已经不堪重负,可能会 影响虚拟机的性能和稳定性,没有广泛的测试,问题是很难得以解决和纠正的。 另一个例子,假设一家 IT 企业在卷上部署新应用,与电子邮件系统共享物理驱动器。如果新的应用变得非 常活跃,物理驱动器性能跟不上,那么电子邮件系统将会受到不利的影响。最后,驱动器性能降低促使 RAID 组重建失败,新驱动器重建的数据可以从同等数据传遍其他磁盘组中。 这些存储瓶颈问题的最佳解决方案是什么?例如,需要进行网络升级还是重构?还是部署更多的新阵列? Martin 非常热衷在存储子系统里使用 SSD 技术。 “我们测试 SSD 技术已有一段时间了,现在可以看到存 储访问速度和性能都有了巨大的改善,”他说,“由于 SSD 单位是完全电子化和无活动部件,SSD 通常可以 消除磁盘延迟。例如,一个为 15000 rpm 的光纤通道,SAS 磁盘响应时间为 6 毫秒,Fibre Channel 磁盘响 应时间为 4 毫秒,但 SSD 只需要约 1 毫秒。” 许多组织正在引入 SSD 存储,优化第一级存储应用的性能。然而,缓解存储瓶颈可能真的能够转移问题。 “在某些情况下使用 SSD 技术,我们看到存储瓶颈移动到其他环境中去,比如,网络,” Martin 说,“IT 工作人员应该在引进 SSDs 前后仔细检查存储路径确定存瓶颈变化。”

11 / 50

如何突破瓶颈保持数据中心的领先性?例如,仔细地规划容量问题或其方案,对此您有什么建议? 性能监测和规划一直是数据中心管理重要的一部分, 但是 Martin 认为, 一个数据中心可以通过 SSD 升级, 匹配相应的以太网或存储区域网络来提高性能。 “我们一直都说 SSD 技术与 10 GB 的以太网络和 8 GB/16 Gb 的光纤通道存储区域网络结合效果非常好,”他说,”我相信,SSD 和高速网络是天生的一对。” 然而,机构还不能证明 SSD 能够增强网络性能,所以大部分存储子系统仍还坚持现有的最佳方案。例如, 要小心你的物理存储,甚至在虚拟环境中。这意味着您的 IOPS 需要与驱动器类型相匹配,将工作负载扩展到 可用磁盘上,从相同的 SATA 驱动器或驱动器组运行多个业务关键应用只是要求更多的存储。 此外,考虑到短行程驱动器的最关键性,所以驱动器格式化只能在外层轨道保存数据。这样不仅减少了机 械滞后还增强性能,但废弃的驱动器还存在相当大一部分的存储空间。 最后,一定要使用虚拟化性能监测工具,这将有助于在数据存储和网络业务上的跟踪和报告,以便 IT 管理 员可以发现瓶颈的同时,快速制定最佳的解决方案来处理存储性能问题。 通常, 由于不适当的规划、 意外和意想不到的工作负载导致存储瓶颈的发生, 这都会降低应用程序的性能, 从而影响用户的体验。应用程序引入 SSD 可以克服传统机械硬盘相关问题和显著提高系统性能。

(来源:TechTarget 中国 作者:Stephen J. Bigelow 译者:李洪亮)

12 / 50

解读 vSphere 5.1 VMotion 增强功能

vSphere 5.1 进一步增强了 vMotion 的功能,为虚拟机在线迁移提供了更大的灵活性,在没有 SAN 网络 或者共享存储的情况下就能进行虚拟机的在线迁移。在 vSphere 5.1 之前版本中,如果要想迁移虚拟机所在的 数据存储(Storage vMotion)和虚拟机所在的 ESXi 主机(vMotion)必须分两步进行。而在 vSphere 5.1 中能够同时进行 Storage vMotion 和 vMOtion 操作, 从而也就实现了在没有共享存储的情况下进行 vMotion 迁移的目的。 解读 vSphere 5.1 vMotion 增强功能

如下图 1 所示,两台 ESXi 主机使用的数据存储都是本地存储,虚拟机就建在本地数据存储 中。vSphere 5.1 的 vMotion 增强功能借助 TCP/IP 网络,将虚拟机内存和磁盘数据拷贝至目标主机,从而实 现了在没有共享存储的主机之间同时迁移内存和存储的功能。

图 1. vSphere 5.1 的 vMotion 增强功能 13 / 50

借助网络在一个操作中同时进行 vMotion 和 Storage vMotion 操作,无疑对源主机和目标主机之间的网 络提出了更高要求。 为了解决这个问题, vSphere 5.1 vMotion 继续利用了 vSphere 5.0 中引入的多网卡特性, 而且还能够在多个网络适配器之间网络负载平衡。多适配器特性使用户能够在源主机和目标主机之间部署多个 vMotion 网络接口。初始化迁移操作时 vSphere 5.1 能够基于链路速度匹配源和目标的 vMotion 网络,达到 充分利用链路带宽的目的。为了保证连接的可靠性,在源和目标主机的网络之间建立了 TCP 连接而且能够透明 地在网络连接之间进行负载均衡。 使用 vSphere Web Client 在线虚拟机迁移 在 vSphere 5.1 之前的版本中,要同时更改虚拟机所在的主机和数据存储,必须关闭虚拟机。换句话说, 当虚拟机处于在线/运行状态时, “更改主机和数据存储”选项是灰色的,要同时更改虚拟机所在的主机和数据 存储必须分两步操作:更改主机、更改数据存储。 在 vSphere 5.1 中,使用 vSphere Web Client 进行虚拟机的在线迁移并不需要进行很复杂的操作:打开 vSphere Web Client 后,单击 “虚拟机和模板”视图,右键单击你想迁移的虚拟机,直接选择“更改主机和 数据存储”即可。

图 2. 在 vSphere Web Client 中执行在线 vMotion 操作

如何提高 vMotion 迁移的成功率 在 vSphere 5.1 之前的版本中进行 vMotion 迁移时,想必我们对如下错误并不陌生:“迁移已超出最大 为 100s 的切换时间上限,ESX 已抢先使迁移失败,以允许虚拟机在源上继续运行。”

14 / 50

图 3. vMotion 迁移失败 造成这个问题的原因是 vMotion 迁移超出了 100s 的限制,在 vSphere 5.1 中同时进行 vMotion 和 Storage vMotion 操作对网络提出了更高的要求,如果配置不当,发生上述操作的概率无疑会更大。那么如何 尽可能提高 vMotion 迁移的成功率呢?在进行 vMotion 操作时建议进行如下配置: 1. 建立单独的 vMotion 网络,分离 vMotion 网络、管理网络和虚拟机所在的生产网络。这样可以避免不 同网络争用带宽,造成网络瓶颈。 2. 如果没有建立单独的 vMotion 网络,建议在非业务高峰期进行虚拟机的迁移操作,这样可以减少生产 网络对 vMotion 网络的影响。 3. 为 vMotion 网络配置多个网络适配器,这样就能够利用 vSphere 5.0 提供的多网卡负载均衡功能,加 快在线迁移速度。 4. vMotion 网络已经能够支持 10Gb 以太网,在条件允许的情况下使用万兆网络提供虚拟机的在线迁移。 5. 如果允许业务停机窗口,那么停止虚拟机再进行虚拟机的迁移将大幅度提高迁移速度,因为虚拟机内存 中已经没有活动数据了。

关于作者:张冀川,TechTarget 中国特邀技术编辑。任职于某国企信息中心,主要负责数据中心系统、 数据库运维管理工作,对存储虚拟化、服务器虚拟化、技术有浓厚兴趣,并在工作中积极应用。 (来源:TechTarget 中国 作者:张冀川)

15 / 50

虚拟机可用性技术纵览: VMware HA vs. FT 和 VADP vs. SRM

VMware 提供了一系列保护虚拟机可用性的功能:HA、FT、VADP、SRM 以及 vMotion。实现最大化虚 拟系统可用性的关键在于了解公司策略以及可利用的技术能够使用哪些特性。下面简要介绍一下在特定的场景 下如何选择 VMware 提供的高可用性特性。 意外的主机宕机:VMware HA vs. FT 到目前为止,VMware vSphere HA 是最容易实现的可用性技术。如果有共享存储而且在 vCenter 集群中 配置了两台或以上的主机,就能够启用 HA。VMware HA 将预留足够多的容量来应对一台或多台主机发生故 障的情况,而且,出现故障的主机上的虚拟机将会在集群中其他主机上重启。这一特性将会快速恢复虚拟机, 而且虚拟机宕机时间很短。 如果你选择 VMware vSphere FT,就不会出现 HA 产生的短暂宕机时间。当你在虚拟机上启用 FT 时,将 会在第二台主机上创建虚拟机的影子版本。当主虚拟机执行会话时,影子虚拟机会执行完全相同的操作。影子 虚拟机是精确的副本,除非 vSphere 阻碍了写磁盘或者与影子虚拟机基于网络的通信。如果运行主虚拟机的主 机发生故障,第二台主机将会为第二台虚拟机提供全功能的读写访问以及网络连通性。这一转变足够快,运行 在虚拟机之上的应用程序不会受到影响。 使用 VMware FT 时有一些注意事项,最为明显的就是被保护的虚拟机只能配置一颗 vCPU,而且每台主 机只能容纳四个受保护的虚拟机。 预期的主机宕机:VMware vMotion 当 VMware 管理员将主机置于离线状态时, VMotion 能够用于在主机之间迁移虚拟机。 执行 vMotion 操 作通常只会丢失很少的数据包,对于基于 TCP/IP 的应用程序来说,这都是能够容忍的。为了保证关键应用的 在线时间,VMware vMotion 是一个不可或缺的特性。 虚拟机备份与恢复:VMware VADP vs. SRM

16 / 50

VMware 引入了 VADP, 为 vSphere 用户提供了备份应用程序直接访问虚拟机文件的一个标准 API 集合。 如果备份工具厂商选择使用 VADP, 那么 VADP 的变化块追踪技术使主机能够追踪上次备份完成后虚拟机文件 发生变化的数据块。尽管没有实现虚拟机自动恢复,但是 VADP 允许组织将虚拟机备份为易于恢复的格式而且 只需要对配置进行很小的调整就能够执行。 为了实现基于 vSphere 的整个数据中心的自动恢复, 可以尝试一下 VMware 提供的附加产品 SRM。 SRM 基于 vSphere 或者基于阵列的存储复制技术,将虚拟机复制到恢复站点。你需要在恢复站点配置完整的 vSphere 基础设施。一旦恢复站点的数据是可用的,SRM 将会自动执行相应的操作确保位于恢复站点的 vSphere 主机能够使用存储,以合理的顺序注册并重新配置并开启虚拟机。和其他的备份以及恢复计划相比, SRM 能够显著减少与数据中心发生故障相关的宕机。一定要在 SRM 计划的业务层面而不只是在技术方面投入 时间及精力。 正确地使用 VMware 提供的所有可用性技术能够显著改善基于虚拟机的应用程序的可用性。

(来源:TechTarget 中国 作者:Brian Knudtson 译者:张冀川)

17 / 50

通过 vSphere DRS 优化负载均衡

DRS 可以在 VMware vSphere 系统中自动平衡工作负载,这对服务器性能和电源使用率很有益处。该工 具在硬件资源利用率方面带来的优势,是人们在上世纪 90 年代时无法想象的。通过 VMware 管理员的输入来 细化 DRS 功能可进一步优化负载均衡。 VMware 的 DRS(Distributed Resource Scheduler)是很多 vSphere 环境中不可或缺的一部分,因此 管理员理所应当考虑它, 而且只需简单的配置和操作。 但是注意一点: 不是所有的 vSphere 版本都包含 DRS。 VMware vSphere DRS 可以做什么 VMware 把 vSphere DRS 的角色描述为“基于业务优先级自动实现在不同宿主机之间的资源利用率负载 均衡,以及通过在负载较低时段内关闭部分主机优化电源消耗。”DRS 可以帮助 VM 的初始安装、负载均衡和 保持数据中心最大程度地节能。 VMware DRS 执行 VM 在宿主机上的初始安装。 假设在一个 ESX/ESXi 集群服务器组中添加一个新的 VM。 DRS 检查集群中不同宿主机的负载情况,然后选择合适的宿主机创建新 VM。假设三台宿主机 A、B 和 C, A 和 B 主机大多数资源已经用到,vSphere DRS 将在未充分利用的主机 C 上开始新的 VM。 DRS 持续地监控集群中可供宿主机使用的资源, 然后给出运行中 VM 建议来平衡和最大化地利用这些空闲 资源。例如,在 A、B 和 C 宿主机的集群中,所有的 VM 使用的内存和 CPU 资源类似。如果 A 和 B 主机每台 运行 5 个 VM,而 C 主机仅支撑了 2 个 VM,DRS 可能会建议从主机 A 和 B 迁移一台 VM 到 C 上。这样 A 和 B 都支持 4 台 VM,平衡了资源。根据您配置的不同,DRS 可以只是建议迁移或实现执行。这完全取决于您。 DPM(Distributed Power Management)是 DRS 的可选功能。当 DPM 启用时,DRS 评估集群宿主机 现在和过去的使用情况,然后可以自动地(或配置为建议管理员)把主机置于待机状态直到需求增长。通过在 DRS 中启用 DPM,vSphere 可以实际减少数据中心的电源消耗和制冷需求。请把 DPM 作为绿色节能技术来 对待。 DRS 需求:不包含所有 vSphere 版本

18 / 50

截止 2013 年 4 月,VMware 还没有在所有授权包中集成 vSphere DRS。要获得 DRS 功能,您需要购买 vSphere Enterprise 或 vSphere Enterprise Plus 级别的授权。VMware 在 vSphere Standard、Essentials 或 Essentials Plus 版本中都省略了 DRS。把 DRS 定位限于更为高级(和昂贵)的 vSphere 方案中,VMware 可能会阻碍小型 IT 机构接受 DRS。如果您保持中立态度,可以测试 DRS 来决定是否这些优势值得花钱购买对 应的 vSphere 版本,以及适合您的特殊使用环境。 要开启和使用 DRS,您需要集群中至少 2 台服务器,而且它们必须支持 vMotion。在只有一台宿主机可 选的环境中,DRS 不能实现负载均衡或提供 VM 初始安装建议。 DRS 将接管的 VM 磁盘需要位于可以被集群内主机共享访问的存储设备上。 否则,您无法在宿主机之间迁 移 VM。 如何配置和运行 DRS DRS 的配置很简单。一旦您在 vSphere 中配置了集群,右键单击目标集群并选择 Edit Settings。出现的 选择框中的选项为 Turn On vSphere DRS。vSphere DRS 菜单提供了额外的 DRS 选项,例如 不同的自动化 级别 (纯手动、半手动、全自动和设置迁移条件)。 VMware 对每个选项提供了简单清晰的解释。 但是您需要很好地理解自己的独特环境, 做出最适合的选择。 另外, vSphere 在 DRS 的设置上提供了更为精细的手动配置管理, 例如关联规则、 找到底层的 vSphere DRS 和规则。 例如, 当您了解到特定的 VM 跟其它的 VM 交互密切, 关联规则可以让特定的 VM 留在某台宿主机上。 反关联规则将会迫使 VM 运行于不同的宿主机上。这种规则的使用举例,如果一台宿主机失效,位于其它宿主 机上的反关联 VM 将不会受到影响。 要想简单地了解 vSphere Client 现有的 DRS 配置情况,选中集群,然后点击 DRS 页。这里会显示您集群 的属性,此外还有 Recommendations、Faultsand History 选项。要启用 DRS 建议,选择 Run DRS,将会 生成一组改善建议,您可以通过选择 Apply Recommendations 来执行。History 显示出过去的动作。我建议 在任何时候您对 vSphere 做了大改动之后都运行一次 Run DRS,例如增加、移除或迁移多个 VM 之后。这是 主动保持集群运行效率的好方法。

(来源:TechTarget 中国 作者:Mak King 译者:李哲贤)

19 / 50

部署 VMware vCenter SRM 时的三大注意事项

VMware vCenter 站点恢复管理器(SRM)可以作为实施虚拟化环境灾难恢复(DR)计划的一个有效工 具。它可以在数据中心和灾难恢复站点之间实现自动化故障转移,在不中断生产环境的情况下对故障转移计划 进行测试。对于关键业务环境必不可少:它可以保证应用程序的正常运行时间并减少灾难恢复计划的测试。 但是如果在实际部署 SRM 之前没有对一些关键因素进行考虑,你可能会遇到各种各样的问题。事实上, 安装 VMware SRM 是实施 SRM 的最后一步,在你理解和解决各种各样的问题之后,才应该进行部署。这篇 文章列出了三个特别注意事项:虚拟机(VM)布置、应用程序依赖关系和全面的灾难恢复计划。第一部分我 们先来看虚拟机布置。 虚拟机布置 对于 VMware SRM, 简单地将所有的虚拟机存储在一个 SAN 当中是远远不够的。 对于成功的 SRM 部署, 虚拟机在存储区域网络(SAN)中的位置也是十分重要的。 为什么虚拟机位置十分重要?首先,虚拟机位置可以影响 SAN 的复制。VMware SRM 依赖于 SAN 提供 的复制技术。VMware SRM 不能管理或者提供这种技术;它需要的只是其可用、恰当配置和可操作性。大多 数 SAN 复制技术在逻辑单元号 (LUN) 层进行复制, 意味着只能以整个 LUN 决定是是否复制。 这样的结果是, 组织必须确保需要通过 VMware SRM 保护的虚拟机被存放于同一个可被复制的 LUN 当中 (否则 SRM 将不能 提供保护)。一些组织可能会在第一次安装和配置 SAN 复制时考虑解决虚拟机放置问题。如果没有,就需要 在安装 SRM 之前解决这个问题。幸运的是,你可以使用 VMware Storage VMotion 实现在没有宕机的情况 下将虚拟机在数据存储间进行迁移。 其次,虚拟机位置重要的原因是 VMware SRM 在操作时需要同时移动整个 LUN(或者 数据存储)。在 SRM 故障转移过程中,有些虚拟机不能同时进行移动,就需要将它们放置于不同的 数据存储当中。只有当灾 难恢复过程中, 位于同一个 数据存储的所有虚拟机可以同时进行故障转移的情况下, 才可以将虚拟机放置于同 一个 数据存储当中。 同样, Storage VMotion 可以在没有产生宕机的情况下将虚拟机移动到恰当的 数据存储 之中。

20 / 50

为了解决这个注意事项, 组织需要在文档中明确规定虚拟机在 SAN 中的存储位置。 一旦位置被确定下来, 就需要对一些虚拟机进行迁移, 比如将虚拟机移动到可复制的 LUN 之中, 实现通过 VMware SRM 进行保护。 直到 SRM 实施过程中才会进行另一部分必要的迁移。拥有这些文档可以简化之后的迁移过程。 应用依赖关系 必须完全理解应用程序的依赖关系并且将其记载在文档之中。VMware SRM 可能会改变被保护虚拟机的 IP 地址, 但是其不能解决应用程序依赖关系的问题。 计划实施 VMware SRM 的 IT 部门如果没有对应用程序依 赖关系进行理解,那么注定是要失败的。 在完全了解应用程序的依赖关系之后,一些虚拟机可以由 VMware SRM 进行保护,但是其他一些为被保 护虚拟机提供服务的机器仍然处于没有保护的状态。所以,如果当灾难恢复发生时,被保护的虚拟机虽然被移 动到了指定的故障转移站点,但是由于失去依赖的服务,应用程序运行时还是会发生错误。或者,虚拟机以错 误的顺序启动了,在从其他虚拟机需要的底层服务启动之前,具有依赖性的应用程序就尝试启动了。在这两种 情况下,了解应用程序间如何相互作用可以帮助 IT 部门恰当地部署 VMware SRM 来修复依赖性问题。 一些应用程序的依赖性更加明显。比如在一个组织当中,通常情况下应用程序或者中间件服务器通常要和 底层数据库服务器同时进行故障转移。但是更加微小的依赖关系容易被忽视。不要忘记考虑非虚拟化环境中的 依赖关系。 为了解决这个顾虑,组织应该详细地列出应用程序间的依赖关系和相互作用图,拥有了依赖关系图之后, 组织可能会发现为了满足第一个注意事项,可能需要将其他的虚拟机进行迁移。组织可能还需要改变 SAN 的 复制配置。但是完成 VMware SRM 的安装和配置之后,至少组织可以准备创建灾难恢复计划,而保证应用程 序能够以正确的顺序进行启动了。 详尽的灾难恢复计划 尽管这可能是显而易见的,但是仍然要注意 SRM 只能用于数据中心的虚拟化部分。所以你仍然需要一个 为数据中心余下的物理机器制定一个完善的灾难恢复计划。VMware SRM 可以为非虚拟化资源提供集成特性 ——比如运行脚本来控制网络设备——VMware SRM 的正确定位为:灾难恢复策略中的一个组成部分。组织 仍然必须定义灾难恢复事件,比如怎样才能构成一个合格的灾难恢复事件,组织仍然必须定义多个角色来表明 灾难事件中的任务分配。VMware SRM 不能替换这些角色,但是 VMware SRM 需要组织这些定义来使得这 项技术可以适用于灾难恢复策略。寻求以技术作为策略的组织最后会发现很难达到项目的成功准则。

21 / 50

另一方面,如果一个组织能够认真地检查所有这些注意事项,那么其 VMware SRM 的实施过程将会十分 顺利。安装 VMware SRM 时,虚拟化部门会发现这个过程不再复杂,项目当中也不会包含太多的任务,其实 原本就应该这样。

(来源:TechTarget 中国 作者:Scott Lowe 译者:王学强)

22 / 50

VSphere Metro Storage Cluster:可在一个集群中实现跨站 点 HA 和 DRS

IT 组织需要更大级别的弹性, 将负载分发至他们的虚拟化环境中。 而 VMware 的 vSphere Metro Storage Cluster(vMSC)就可以实现这个需求。 通过 vSphere Metro Storage Cluster ,IT 组织可以将处在两个地点的 vSphere 架构独立开,但却将它 们当成同一个数据中心,作为一个集群来管理。(当然,vCenter 服务器在没有 vMSC 的情况下也可以管理两 个节点,但这是不推荐的。通过 vMSC,你可以在一个 vCenter 集群中管理两个节点。) 只有少数 IT 组织的业务需求和基础设施能从 vSphere Metro Storage Cluster 中得到好处,但这对于少 数用户(比如金融贸易公司,联邦政府,大交易量的网站等)来说,vMSC 利用 VMware 高可用性(HA)和 VMware 分布式资源调度器(DRS)在两个数据中心之间实现业务弹性和负载均衡,这在 VMware 的环境中 是其他办法不可能做到的。 有一些用户的需求列表中要求提供如下功能: 一个 IT 组织需要两个数据中心, 他们之间至少具备 622Mbps 的带宽,并且有双活的 SAN 网络。最大网络延时不能超过往返 10ms。虽然 vMSC 可以带来一些灾难恢复的 好处,但它并不是一个 DR 解决方案。 此外,VMware HA 无法感知站点,所以有很多功能你都无法控制。VMware DRS 也无法感知站点,所以 尝试创建规则来实施控制是有挑战的。其他高级功能诸如存储分布资源调度器(SDRS)也无法感知站点。 vMSC 的网络配置很复杂,它需要特殊的网络方案来支持,如覆盖传输虚拟化(OTV)。最终,集群中 VM 的日常管理操作会变得更加麻烦,因为传统的任务,如备份、恢复,vMotion 和灾难恢复都需要将 vMSC 考 虑进来。 要配置一个 vMSC 集群,你需要一个在 vCenter 中创建 vSphere 集群,它包含多个双活的 ESXi 主机。这 些 ESXi 主机位于不同的物理地点,它们既可以在同一个城市,也可以分布在更大的区域内。

23 / 50

双活同步存储的需求通常是通过“延伸 SAN”或使用分布式虚拟存储来实现。一个延伸 SAN 涉及创建多 个虚拟 SAN(VSAN),并且配置 VSAN 间路由,只有主站点是可读写的(和备站点的距离通常限制在 100 公里以内)。分布式虚拟存储涉及到一个集群文件系统和缓存。 VMware vSphere Metro Storage Cluster 白皮书(如果你打算部署 vMSC,我强烈推荐将此白皮书作为 你的设计向导)提供了站点间网络的特定需求: ? 站点之间最大支持 VMware ESXi 管理网络的网络时延是往返 10ms。 ? vMotion 中 10ms 的延时只有在具有 VMware vSphere Enterprise Plus 版本许可中才支持,这个版本 许可包括 Metro vMotion 功能。 ? 同步存储复制的链路最大支持 5ms 的往返时间。 ? ESXi vMotion 的网络需要最少 622Mbps 的网络带宽,并且有冗余链路。 VMware 现在提供 vSphere Metro Storage Cluster 白皮书,并且对存储做 vMSC 兼容性认证,这清楚 的说明 VMware 计划对 vMSC 提供更多的支持。毋庸置疑,VMware 会提升 vSphere 和 vCenter,使它们及 时支持 vMSC。 但是在两个或多个数据中心、 两个或多个高级 SAN 架构、 高级网络设备和 vSphere Enterprise Plus 许可的环境中,vMSC 带来的大额开支依然是阻碍 vMSC 发展的一大问题。 客观的说,vSphere Metro Storage Clusters 对于大多数企业来说并不是一个合适的解决方案。但是,在 跨多个高可用性节点、负载分发和有资金来支持至少两个数据中心间低延迟与高带宽的环境中,你就可以考虑 使用 vSphere Metro Storage Clusters。

我第一次听到“延伸集群(stretched clusters)”是在 VMware 设计专家认证(VCDX)上,作者 Scott Lowe 在 2011 年 Carolinas VMware User Group 用户沙龙也提到了这个词。 我看了 Scott 50 分钟关于 vMSC 的演讲(延伸集群设计的优缺点)。从那时起,他开始在博客上发表 vMSC 的文章。我知道的大部分 vMSC 的知识都是从 Scott 学来的。 ——David Davis。 (来源:TechTarget 中国 作者:David Davis 译者:周游)

24 / 50

对比 vMotion 与动态迁移之间的细微差异

对初学者来说,VMware 的 vMotion 与微软的动态迁移非常相似。它们都是在不停机(或者只有几毫秒 的中断)的情况下在不同主机之间迁移运行的虚拟机。可以肯定的是每家厂商都会说自身的产品更加出众,究 竟孰优孰劣?让我们一起来解决 vMotion 与动态迁移之间的争议。 对比动态迁移和 vMotion 就像对比上等的葡萄酒。只有你花时间研究才能够看到两者之间细微的差异。 很少有人消耗时间和资源来研究 vMotion 与动态迁移。为了帮助你加速对两者的了解,我来解释一下它们之 间的细微差异。 虚拟机迁移的短暂历史 2003 年,VMware 发布了 GSX 和 vCenter,其中包括 vMotion。VMware 的 vMotion 实际上是服务器 虚拟化的首个“啊哈”特性。vMotion 过程看起来太简单以至于难以置信。我记得测试过程——在迁移过程中 使用虚拟机并检查迁移前后虚拟机的路径——在之前我真的以为虚拟机已经迁移了。不只是我,VMware 的 vMotion 让很多服务器虚拟化管理员都相信了。 微软在 Windows Server 2008 Hyper-V 中提供了快速迁移。使用快速迁移时,虚拟机处于静默状态,内 存被写入磁盘,虚拟机内存被迁移至另一台 Hyper-V 主机,然后被恢复。这一过程耗时而且虚拟机不在线。 在 Windows 2008 R2 中,微软使用动态迁移取代了快速迁移。当在不同 Hyper-V 主机之间迁移虚拟机 内存时,虚拟机仍旧是可用的。和之前的 vSphere 版本一样,动态迁移需要使用共享存储。 vMotion 和动态迁移的新特性是什么? Windows Server 2012 中,动态迁移不再需要共享存储。此外,使用 Hyper-V 2012,你可以同时执行 多个动态迁移任务。该特性令管理员能够在本地或者服务器信息块(SMB)存储上存储虚拟机,而且能够在不 停机的情况下迁移虚拟机。Windows Hyper-V 2012 动态迁移还支持 10Gb 以太网。 Windows 2012 Hyper-V 动态迁移最具争议的是,微软声称组织能够同时执行无数量限制的动态迁移任 务。

25 / 50

VMware 在 vSphere 5.1 中进行了改进,将 vMotion 和 storage vMotion 整合进了单个操作中。最后的 结果就是不需要共享存储就可以进行 vMotion 了,这提供了与 Hyper-V 2012 动态迁移相似的功能。只有在 使用 vSphere Web Client 时才能调用 vMotion 的这一增强功能, 而且该功能只包括在 vSphere Essential Plus 及以上版本中。VMware 指明采用 1Gb 网络连接时,每台主机 vMotion 的最大并发数是 4,如果采用 10Gb 网络,那么每台主机 vMotion 的最大并发数是 8。 vMotion 与动态迁移的性能差异 最后,vMotion 与动态迁移主要的差异在于性能和打包。 只有 vSphere Essential Plus 及以上版本才能使用 VMware vMotion。而在 Hyper-V Server 2012 的免 费版本中就能够使用微软的动态迁移。免费版没有本地图形用户界面,但是却包含了商业版才具有的某些高级 功能。 微软声称的无限制的动态迁移并发数引发了争议:该声明究竟是事实还是谬论?正如很多专家指出的,声 称软件没有规模的限制非常不可靠。 这导致了 VMware 专家的拍砖,指出无限制的动态迁移并发既不明智也不切合实际。两位 VMware 专家 表示,智能软件公司不应该说他们的产品可以“无限扩展”,而是应该提供可支持的、测试过的配置最大值。 在一个 VMware 委托的研究中, PT 公司发现 vSphere 5 vMotion 的平均迁移速度要比 Windows Server 2008 R2 SP1 快 5.4 倍。研究还发现和 vMotion 相比,动态迁移对应用以及操作系统的性能影响更大。至今, 还没有类似的研究对 Windows 2012 Hyper-V 动态迁移和 vSphere 5.1 vMotion 进行对比,微软也没有声明 动态迁移对应用以及操作系统的性能影响已经得到了补救。 如果动态迁移以及 vMotion 之间的这些性能差异仍旧存在,并且大量的动态迁移被应用于大型企业或者 服务提供方,那么这些性能差异将会成倍增加,而且可能会导致服务器性能的退化。 vMotion vs. 动态迁移:结论 进行了这么多的比较,差异可能取决于你更相信哪家厂商。VMware vSphere 无疑是历史最久,市场份额 最大的产品,而且已经赢得了多数数据中心和服务器管理员的信任。另一方面,微软的动态迁移是挑战者而且 必须赢得全世界 IT 管理人员的信任。虽然动态迁移是新产品,却并不意味着不如 vMotion 可靠。

26 / 50

正如很多产品或特性看起来很相似, 实际上只有你施加了压力才会知道其扩展性有多大或者是有多么可靠。 例如,两辆赛车看起来很相似,但是如果不开上赛道,你的确不知道它们能跑多快或者能够以某个速度行驶多 少公里。请将此牢记于心,如果你对 Hyper-V 2012 感兴趣,鼓励亲自行测试并验证你的想法。然而请记住, 动态迁移虚拟机只是整个 hypervisor 软件包众多功能的一个方面。毕竟虚拟化的博弈不只是 vMotion 与动态 迁移。你应该将虚拟化的博弈看作是 vSphere 以及 vCloud Suite 与 Windows Server 2012 以及 System Center 2012 的对比。

(来源:TechTarget 中国 作者:David Davis 译者:张冀川)

27 / 50

Hyper-V 动态迁移原理详解

为了追赶上 VMware 虚拟化霸主的脚步, 微软从 Hyper-V 2.0 开始支持物理机与虚拟机之间的动态迁移。 动态迁移对于实验室来说,需求可能并不高;但对于企业来说,这却是虚拟化成熟度的一个分水岭。 在开始之前,需要明确一个概念。 动态迁移(Hyper-V Live Migration)并非故障状态下的非计划宕机。 该应用场景仅用于升级、硬件更换等计划宕机。 动态迁移步骤: ? 在源和目标计算机之间建议连接 ? 传送虚拟机配置及设备信息 ? 传送虚拟机内存 ? 暂停(挂起)源虚拟机并传送状态 ? 恢复目标虚拟机 一、在源和目标计算机之间建议连接 该部分的通信涉及到两个 WMI 对群集中两个 dll 的调用: clusres.dll 群集资源管理 dll(基本的网络、存储、WINS、DHCP、脚本。。) vmclusres.dll 虚拟机群集资源管理 dll

28 / 50

Live Migration 从本质上来说还是群集的一种实现方式。 通信的速度与效率与源服务器和目标服务器的负载有关。 在源服务器或目标服务器负载过高情况下会出现 WMI 调用 clusres.dll 超时失败的情况。 该场景出现在 PRO 调用 Live Migration 过程中,将会造成第 4 步,即暂停(挂起)源虚拟机并传送状态 卡死,导致虚拟机长时间处于挂起状态。 错误信息如下: 错误 (12711) 由于出现错误 [MSCluster_Resource.Name="SCVMM XXX01 Configuration"] ,找不到元素,VMM 无法在服务器 HOST01.contoso.com 上完成 WMI 操作。 详细信息 (找不到元素(0x490)) 微软提供的相关的补丁,需要在所有节点上部署: http://support.microsoft.com/kb/974930 二、传送虚拟机配置及设备信息 这里值得注意的是,该部分传送的并非虚拟机目录中的 XML 配置文件,仅仅是注册表中的信息。 以上两步完成的是迁移的准备工作,告知了目标服务器虚拟机所需的资源,并分配所需资源。 三、传送虚拟机内存 该部分是迁移的核心技术部分。不论是 VMware 还是 Hyper-V 来做迁移,都是无法逃避的问题。 那些销售所谓的服务不会断线,不过是传说。从技术的角度来说只是断线的时间由秒这个级别降低到了毫 秒级而已。 我们来详细描述一下内存传送的过程: 1、锁定 Guest 主机内存,并将该部分的信息传送到目标服务器。 29 / 50

2、Guest 主机继续运行,在 Host 主机中开启一个新的内存分区为 Guest 主机提供服务。该区域仅保存 变更的内容。

3、新内存分区将继续分片锁定,并传送。

4、重复 2~3,保证原 HOST 服务器与目标 HOST 服务器变更内存的差异在一个极小的时钟周期之内,直 至操作 1 中的内存传送完成。 四、暂停(挂起)源虚拟机并传送状态

30 / 50

这部分包含 3 个操作: 1、挂起源虚拟机 2、传送最后的源虚拟机内存变更片段 3、通知存储,将存储挂载至目标服务器 第四步是迁移时间消耗的关键。 而关键的关键是实时内存状态的保存。 在 Hyper-V 1.0 中 Quick Migration 采取的方式是挂起源虚拟机,再处理内存的方式。 所以在迁移过程中会发现宕机的时间与虚拟机所消耗的内存量成正比。 而在 Live Migration 中,宕机时间不再由所迁移虚拟机消耗的内存来决定。 决定宕机时间的关键点内存大小是一个相对较小的变更内存片段。 根据实测,在 Live Migration 操作中,ping 包监视根据系统负载不同在丢包为 2~6 之间。 完全可以满足一般企业高可用的需求。 五、恢复目标虚拟机 这个部分与普通的恢复相同。不做详细说明。

(来源:TechTarget 中国 作者:吴炫国)

31 / 50

使用 SCVMM PowerShell cmdlets 自定义 Hyper-V 热迁移

对于小的 IT 部门来说, PowerShell cmdlets 强化了 Hyper-V 的热迁移能力。 但是, 如果能再结合 System Center Virtual Machine Manager 和它的 PowerShell 能力,这些部门就能精确地在不同的节点以及集群共 享卷(Cluster Shared Volume)间直接实现热迁移。 Microsoft System Center Virtual Machine Manager (SCVMM) 包括一个强大的图形用户界面 (GUI) 。 管理员们可以利用它来实现 Hyper-V 的热迁移。 尽管如此, 你可能会觉得 SCVMM 缺少管理一个复杂 Hyper-V 虚拟架构所需的精细控制。 但是,SCVMM PowerShell cmdlets 提供远超过图形界面所提供的更灵活的热迁移管理。通过下列 SCVMM PowerShell cmdlets 和脚本,你可以将整台主机的虚拟机热迁移到某特定的节点,或者基于集群共 享卷(Cluster Shared Volumes)的分配来迁移虚拟机。 (备注:你必须在你运行脚本的服务器或工作站上安装 SCVMM 控制台)。 将一个节点上的所有虚拟机迁移到另一个节点 维护模式是一个 SCVMM 图形控制台中的特性, 它采用一种智能布局算法来将你选择的节点中的所有虚拟 机分布到集群中其它节点。但是如果你希望保持虚拟机的组合,只是想将它们迁移到某一个其它节点上呢? 例如,在我的虚拟架构中,集群中有不同的负载分担应用。将负载均衡的虚拟机工作负载置于一个相同的 集群节点上会限制负载均衡的效果,特别是在某台主机故障的情况下。 另外,通过在目标节点保持同样的虚拟机混合,你已经知道对资源的负载会是如何。从我的经验来说,即 使是集群中有一个完全空置的节点,SCVMM 的维护模式并不总是将原节点的虚拟机都分布到这个空置的节点 上。这是因为 SCVMM 的智能布局算法持续地从各主机收集负载参数来决定最好的虚拟机布局。因此当空置节 点接收到虚拟机后,它的布局分数下降,导致 SCVMM 将余下的虚拟机分布到其它的集群节点中。 在图形界面中,唯一能够强制让某个节点的所有虚拟机都热迁移到另一个特定节点的方法是,人工通过每 一台虚拟机的迁移向导来实现。但是下面这个脚本能够覆盖智能布局算法并将虚拟机们同步到一个特定的集群 节点上。你只需要很简单的回答几个提示。 32 / 50

# -----------------------------------------------------------------------------# Migrate All VMs to Alternate Node in the Same Cluster # -----------------------------------------------------------------------------Add-PSSnapin Microsoft.SystemCenter.VirtualMachineManager $VMM = Read-Host "Enter Name of VMM Server" $SH = Read-Host "Enter Source Host Name" $DH = Read-Host "Enter Destination Host Name" Get-VMMServer -computername $VMM Get-VM | ? {$_.hostname -like "$SH*"} | Move-VM -VMHost "$DH*" 通过以下步骤来运行这个脚本: 1.将上面的 SCVMM PowerShell 脚本保存下来(例如保存 MigrateAllVMsOnNode_SCVMM.ps1); 2.打开 Windows PowerShell; 3.运行脚本; 4.回答对于 SCVMM 服务器、源节点名以及同一个集群中的目标节点名的提示。

5.通过观察命令状态,Failover Cluster Manager 或者 SCVMM 的任务页来监视迁移进度。

33 / 50

在节点间对于一个集群共享卷(Cluster Shared Volume, CSV)上的虚拟机进行迁移 这个脚本识别一个特定集群共享卷上的虚拟机,并将他们热迁移到某特定的目标节点。使用这个脚本来将 一个集群共享卷上的虚拟机在热迁移后保持在同一台主机上。

34 / 50

你为什么会需要这样做?在通常的集群操作中,一个虚拟机可以直接访问一个被很多节点共享的卷,并且 那个集群中的其它节点也能同时利用这个节点的资源。但是当你使用 Microsoft Data Protection Manager 或者其它基于 Hyper-V 卷影副本(VSS)的备份工具时,问题就出来了。在备份的过程中,只有拥有这台虚拟机 的主机能够直接访问磁盘。处于其它节点中,并共享该相同的集群共享卷的虚拟机,则需要通过网络来访问磁 盘,这扩大了磁盘的延时以及降低了性能。

为了避免这个情况, 指定下列的布局架构来对所有共享 CSV 的虚拟机都维持全性能的磁盘访问。 在使用维 护模式后,通过使用这个脚本来轻松地将某个 CSV 上的虚拟机都热迁移到所需的节点上 # -----------------------------------------------------------------------------# Live Migrate Virtual Machines On a Particular Volume to a New Host in Same Cluster 35 / 50

# -----------------------------------------------------------------------------Add-PSSnapin Microsoft.SystemCenter.VirtualMachineManager $VMM = Read-Host "Enter Name of VMM Server" $SH = Read-Host "Enter Source Host Name" $DH = Read-Host "Enter Destination Host Name" $Vol = Read-Host "Enter Volume/CSV Volume to Move VMs to Destination Host" Get-VMMServer -computername $VMM Get-VM | ? {$_.hostname -like "$SH*"} | ? {$_.Location -like "*$Vol*"} | Move-VM -VMHost "$DH*" 通过下列步骤来运行这个脚本: 1.将上面的脚本保存(例如 MigrateAllVMsByVolume_SCVMM.ps1); 2.打开 Windows PowerShell; 3.运行你保存的上述脚本; 4.回答对于 SCVMM 服务器、源节点名、目标节点名以及你想指向的集群共享卷(CSV)。

5.通过观察命令状态,Failover Cluster Manager 或者 SCVMM 的任务页来监视迁移进度。 对于 SCVMM PowerShell cmdlets 进一步的实验 上面的脚本仅仅是两个你能使用 SCVMM PowerShell cmdlets 的例子。 由于 SCVMM 深度采集每台虚拟 机的信息,有更多的方法能够将特定虚拟机包括或者排除在热迁移中:
? 名字:你可以对于某个特定的名字属性来热迁移虚拟机(例如使用-like 命令选项);

36 / 50

? 内存:你可以指向处于某内存临界之上或之下的虚拟机; ? 操作系统:你可以通过操作系统来选择虚拟机,例如 Windows、Linux(仅快速迁移)等。

通过 SCVMM PowerShell cmdlets,你能够较采用图形控制台更深度地定制你的热迁移方案。System Center Virtual Machine Manager 2012 会在升级的 cmdlet 中添加更多的选项。但是图形界面仍将缺少精确 的管理功能。因此,学会使用 SCVMM PowerShell cmdlets 来简化管理任务,会对你受益匪浅

(来源:TechTarget 中国 作者:Rob McShinsky 译者:徐扬阳)

37 / 50

Hyper-V 动态迁移失败的常见原因

在生产环境中运行微软 Hyper-V 的大多数组织都认为动态迁移是一个非常关键的功能。 动态迁移失败可能 带来毁灭性的结果, 而一些配置错误可能导致动态迁移的失败。 了解导致 Hyper-V 动态迁移失败的常见因素能 够将问题扼杀在摇篮里。 没有足够的资源 Hyper-V 不能进行动态迁移 导致动态迁移失败的最常见的问题之一同样也是最容易纠正的。为了将虚拟机从一台主机动态迁移至另一 台主机,目标主机必须具有足够的物理资源来承载该虚拟机,比如足够的物理内存。如果目标主机没有足够多 空闲的物理内存(或者其他物理硬件资源),那么动态迁移将以失败而告终。 问题的解决办法很简单。管理员将虚拟机迁移到其他具有足够硬件资源的主机或者关闭目标主机上优先级 较低的虚拟机,腾出空间和资源。 处理器不兼容将导致迁移失败 微软 Hyper-V 不需要集群节点使用完全相同的硬件。然而, Hyper-V 集群中的每台主机服务器必须具有 类似的处理器用于动态迁移。意思是你需要确保所有的物理主机处理器出自相同系列。换句话说,你不能够将 虚拟机从一台配置了 Intel 处理器的物理主机迁移至配置了 AMD 处理器的物理主机之上。 有时使用类似的 CPU 型号还不足以满足动态迁移的条件。例如,几周前我决定将配置 6 核 AMD 处理器 的服务器替换为 8 核 AMD 处理器的新服务器。原本计划将这些新的服务器添加到现有的 Hyper-V 集群中, 将 VM 从旧服务器动态迁移到新服务器,然后将这些旧服务器下线。不幸的是,由于处理器指令集差距过大导 致了动态迁移的失败。 通过将 VM 配置为使用处理器兼容模式,我成功地完成了动态迁移。 处理器兼容模式存在缺陷

38 / 50

处理器兼容模式看起来像是解决了处理器不兼容的问题,但存在缺陷:只能够在同一系列的处理器之间进 行动态迁移。你不能够在 Intel 和 AMD 处理器的主机之间进行动态迁移。然而,你能够使用这一模式在同一 厂商或者同一系列的不同时期的 CPU 之间进行动态迁移。 这一模式截断了 CPUID 指令这样就掩盖了实际的 CPU 识别过程。反过来说,采用这一模式禁用了一些能 够提升处理器性能的特性。如果你在使用 VM 进行多媒体或者高性能计算,或者说 VM 在执行 CPU 密集型加 密运算时,微软建议不要使用处理器兼容模式。 为了启用处理器兼容模式,你必须关闭 VM 然后重启。在某些情况下,你可以将已关闭的 VM 迁移至目标 主机上。事实上,在这种情况下处理器兼容模式就不是必须的了。 Hyper-V 版本不匹配,iSCSI 不兼容以及网络连接缓慢 故障转移群集中不匹配的 Hyper-V 版本可能导致动态迁移失败。集群可能由多个 Windows Server 版本 组成,只要是每个 Windows Server 的副本属于同一个发行周期即可。例如,你不能在一个故障转移群集中混 合 Windows Server 2008 以及 Windows Server 2008 R2,因为 Windows Server 2008 中的 Hyper-V 不支 持动态迁移。 ISCSI 不兼容同样可能会妨碍动态迁移的完成。在 Windows Server 2012 发行以前,动态迁移需要使用 集群共享卷(CSV)。CSV 能够通过 FC 或者 iSCSI 进行连接。如果你选择使用 iSCSI,那么目标主机必须符合 iSCSI-3 规范,因为动态迁移要用到 iSCSI-3 规范中的持久性保留特性。 最后, 只有网络连接带宽不低于 1Gb 时才能支持动态迁移。 虽然从理论上说在带宽更低的物理链路上也可 能能够完成动态迁移,但是微软并不支持这样做。 很多不同的因素都可能导致虚拟机动态迁移的失败。学习并了解了可能会遇到的导致虚拟机动态迁移失败 的这些最为常见的问题,那么你最好能够避免这些问题的出现。

(来源:TechTarget 中国 作者:Brien Posey 译者:张冀川)

39 / 50

使用 PowerShell 克服 Hyper-V 热迁移限制

微软在 Windows Server 2008R2 系统里改进了 Hyper-V 的热迁移,这也拉近了和对手(Vmware)产品的 差距,但是它仍然有许多的限制。不过你可以使用 PowerShell 命令行工具来热迁移,从而突破这些限制。 管理员利用 Hyper-V 的热迁移, 可以几乎不间断地把一个虚拟机从 Hyper-V 群集节点转移到另一个节点。 当然,还会有少许的中断系统时间,各种各样的虚拟机热迁移都不能避免,这是热迁移的通病,而且各种虚拟 化产品都是以虚拟机的迁移中断时间来作标准。新的 Hyper-V 3.0 改进了 Hyper-V 热迁移的一些限制,现在 通过 PowerShell 命令行工具的确可以看到这些改进。 使用 PowerShell 故障转移命令行工具 大多数的 Hyper-V 群集都用 System Center Virtual Machine Manager (简称 SCVMM)来管理,不过在 只有一个或者极少量的 Hyper-V 服务器的群集的时候, PowerShell 命令行工具可以避免使用 SCVMM 热迁移 时带来的额外中断时间, 让热迁移的过程自动化和策略化。 多数 Windows 群集管理员都熟练使用 cluster。 exe 去管理群集资源,不过 PowerShell 群集故障转移命令行工具还可以用来进行系统的热迁移。 在同一群集中单独迁移虚拟机到另一个节点 下面的 PowerShell 脚本可以让你灵活地迁移虚拟机而不受群集的约束。你所要做的,是确认好群集的命 名,群集虚拟机资源,还有你即将要迁移虚拟机到哪一个目标节点。你也可以修改这个脚本用于迁移多个虚拟 机,这可以让你自动完成热迁移时节点的准备。 有一个要点, 如果你要迁移一个 Windows 7 系统的虚拟机, 你需要安装远程服务管理工具(Remote Server Administration Tools-RSAT)和确认启动了群集的故障转移。一般情况下,启用群集的时候服务器就会自动启 懂 RSAT。 下面的 PowerShell 脚本可以对群集里的虚拟机热迁移: # -----------------------------------------------------------------------------# Migrate Single Virtual Machine With Failover Cluster CMDLet # -----------------------------------------------------------------------------40 / 50

# Necessary to enable failover cluster functions Import-Module FailoverClusters $CL = Read-Host "Enter Cluster Alias Name" $VM = Read-Host "Enter Full Cluster Name Resource Name of VM to Migrate" $DH = Read-Host "Enter Destination Host Name" get-cluster "$CL"| Move-ClusterVirtualMachineRole -name "SCVMM $VM Resources" -node "$DH" 确认你要迁移的虚拟机是启动状态(否则你将会收到一个错误信息),下面是使用脚本的步骤: 1.复制上面的脚本,保存为。ps1 的脚本文件(如:VM。ps1) 2.打开 PowerShell。(开始菜单-程序) 3.运行之前保存的脚本。(如 VM。ps1) 4.填入处于同一群集中的各项应答必填项,群集名称提示,虚拟机群集资源名称和目标节点。

图 1 填好群集属性等提示。

41 / 50

图 2 从群集故障转移管理或者命令状态查看热迁移进程。 在同一个群集里从同一个节点迁移所有的虚拟机到另一个节点 为了把维护工作放在单独一个服务器上,你可能要做一个热迁移,把所有的虚拟机从一个服务器移动到同 个群集里的另一个服务器。你可以使用 PowerShell 命令行代替 Hyper-V 管理器快速地执行虚拟机迁移,或者 做一个小小的修改以适应维护事件或者对节点的失败迁移作出快速的处理。 相对于 Hyper-V 一次只能迁移一个 服务器,PowerShell 命令行简直神了。 这里是同时热迁移多个虚拟机的脚本: # -----------------------------------------------------------------------------# Migrate All Virtual Machines on One Node to Another with Failover Cluster CMDLet # -----------------------------------------------------------------------------# Necessary to enable failover cluster functions Import-Module FailoverClusters $CL = Read-Host "Enter Cluster Alias Name" $SH = Read-Host "Enter Source Host Name" $DH = Read-Host "Enter Destination Host Name" 这脚本的执行步骤和迁移单个虚拟机一样(见上面单个虚拟机脚本运用的说明)。 把脚本保存起来, 运行之, 根据提示填入相应的属性。 42 / 50

现在你应该会觉得 PowerShell 命令行工具非常有用了吧, 稍作修改就能完成你用 Hyper-V 热迁移做不到 的事情。到 VirtuallyAware.com 分享你的热迁移心得吧。

(来源:TechTarget 中国 作者:Colin Steele 译者:赵赛坡)

43 / 50

Hyper-V 热迁移相关项:brownout、blackout 与 dirty 页面

多年来 VMware vMotion 中已经加入了在线迁移技术。近期,微软发布类似的 Hyper-V Live Migration 功能。 毫无疑问,在线迁移会成为 Hyper-V 最受欢迎的功能之一。它可以在集群中实现虚拟机的迁移,而且不会 有明显的服务中断。但事实上,在线迁移过程会引起短暂的服务停止,只是用户经常感觉不到而已。作为管理 员,我们应该去了解它背后不经常涉及的一些项目,帮助监控和诊断服务中断的过程。 Hyper-V 的事件日志中包含了在线迁移过程中存在的会暂时中断虚拟机服务过程的相关信息。 对于每次虚 拟机的迁移过程,该日志记录如下三个事件:管制(brownout)事件、中断(blackout)事件和 dirty 页面 信息、以及在线迁移过程概要。虽然这些日志中包含的信息还不够,但是可以很好地概括出在线迁移的整个过 程。理解这些项目可以帮助我们完成对迁移中出现的时间过长或无法执行管理员任务等问题的故障诊断。 本文中,TechTarget 中国特约专家 Rob McShinsky 将解释如何使用 Hyper-V 日志以及概述日志存放地 点、各项目含义和如何借助这些信息成功完成在线迁移。 如何找到 Hyper-V 在线迁移事件日志 通过 Hyper-V R2 中的 Failover Cluster Administrator、 System Center Virtual Machine Manager 或 相关脚本启动在线迁移过程,可以生成日志报告。 然后在应用程序或者是 Windows Server 2008 事件查看器的 Service Log 部分可以找到相关日志。路径 如下:Application and Services Log -> Microsoft -> Windows -> Hyper-V-Worker。

44 / 50

图1

Hyper-V-Worker 事件日志 找到 Hyper-V-Worker 事件日志后(图 1),右键点击 admin 并通过事件编码筛选日志。Hyper-V 在线 迁移相关事件的编码如下:管制事件(22508)、中断和 dirty 页面事件(22509)、在线迁移过程概要事件 (22507)。 在线迁移管制事件

45 / 50

Hyper-V-Worker 事件日志中首先列举出的是管制阶段。 在虚拟化领域, 管制阶段的定义指的是 Hyper-V 在线迁移过程中用于完成内存数据迁移的阶段。“管制”本身也很好表达了该阶段特点,因为虚拟机不是完全 停止服务(这是“中断”事件的状态)。虚拟机依然可做出响应,但无法做配置更改或其它的管理员操作。

图2

管制事件 图 2 中的管制阶段持续了 19.43 秒,时间长短取决于虚拟机使用的活动内存区域大小以及在线迁移传输网 络的速度。在内存中页面文件向目标站点迁移的过程中,虚拟机始终保持响应。该阶段把跟原虚拟机状态相关 的大多数内容迁移到目标节点,但不是全部。由于虚拟机保持响应状态,也导致客户或许始终不会发现迁移过 程在进行。只是响应时间会延长,通过 ping SERVERNAME –t 命令不断地 ping 虚拟机,我们可以发现在某 个较短时间段内响应时间延长,但服务不会完全中断。

46 / 50

之前我们介绍了如何找到 Hyper-V 在线迁移事件日志以及 brownout 选项功能,现在我们来看看在线迁移中 断和 dirty 页面事件。 Hyper-V 在线迁移的最后一个阶段完成虚拟机向集群中目标节点的完全转移。该过程称为中断阶段,最终 完成虚拟机和所有内存数据的迁移,中间伴有短暂的服务中断期。在中断阶段,主机试图把所有活动内存数据 迁移到目标节点。但在该阶段结束前,原服务器的内存不会清空。通过最后一个快照文件提供关于剩余内存空 间,即 dirty 页面文件的所有内容。当 dirty 文件向目标节点迁移时,中断过程发生。 中断阶段跟 Hyper-V 之前的需要花费大量时间的 Quick Migration 功能完全没有可比性,因为在在线迁 移的这一最后阶段中仅仅涉及极少量数据的迁移。 但是, 会有短暂的中断发生, 通常是一两秒时间, 或一次 ping 无响应。跟管制阶段不同,中断阶段虚拟机不响应。事件日志表示出该阶段持续的时间以及在这一最后阶段中 迁移了多少 dirty 页面(参照图 3)。

图3

47 / 50

中断和 dirty 页面事件 注意, 在对访问量很频繁的工作负载所在服务器做在线迁移时会产生较长的中断时间和较多的 dirty 页面。 这两个 Hyper-V 在线迁移项目很重要,因为中断和 dirty 页面事件是故障诊断的工具之一。从日志中我们 可以看到虚拟机停机时间持续了多久,所以当发生迁移时间超出预期或用户感觉到明显放入服务中断情况下, 可以通过日志查看。 在线迁移概要事件 最后一个事件,22507,给出了在线迁移过程的综述。

图4

在线迁移概要事件

48 / 50

要准确定位哪台机器发生了管制和中断,通过运行 System Center Virtual Machine Manager PowerShell 脚本可以实现。在如下命令中插入虚拟机的唯一标识符找到事件的概要信息: get-vm | where{$_.VMid -eq "Enter VM GUID here"} | ft name 对于任何技术而言,理解每个过程发生的细节对于保持系统长期稳定意义重大。虽然这些事件信息仅仅是 记录一种状态, 但对于 Hyper-V 在线迁移的内部工作机制的了解迟早会在故障诊断过程中起作用。 如果您升级 了在线迁移所用的网卡, 通过日志也可以帮助对比升级前后的效果, 从而判断出是否升级过程提升了系统性能。

(来源:TechTarget 中国 作者:Rob McShinsky 译者:李哲贤)

49 / 50

本期电子书由 TechTarget 出品


相关文章:
VMWare-VMotion迁移虚拟机
VMotion 迁移虚拟机使用 VirtualCenter,可以将虚拟机从一台 VMware ESX Server 迁移到 其他 VMware ESX Server 主机,如果虚拟机保存在共享的存储上,例如 Openfiler...
Hyper-V 实时迁移常见问题
有关实时迁移所需的网络设置的信息,请参见 Hyper-V:实时 迁移网络配置指南。 ...执行实时迁移不需要群集共享卷。您应该了解,使用群集共享卷可以简化群集虚拟机的...
Hyper-V实时迁移指南
Hyper-V实时迁移指南_计算机软件及应用_IT/计算机_专业资料。故障迁移的方法技术...点击管理工具,然后选择“新建 VM”选项,显示如图 5 所示的新建虚拟机 向导对话...
VMware vCenter VMotion 配置
VMotion 在基础 ESX/ESXi 系统之间传输虚 拟机的运行状况。 成功的迁移要求目标主机的处理器能够使用源主机的处理器在 虚拟机迁移出源主机时使用的等效指令来执行...
VMWare向 Hyper-V迁移_方案
VMware 迁移Hyper-VVMware 迁移Hyper-V 前言 本文档是帮助用户进行 VMware 虚拟机向 Hyper-V 虚拟机迁移,提供了迁移前 准备和迁移过程及工具的...
Hyper-V P2V 实时迁移 物理机到虚拟机
Hyper-V P2V 实时迁移 物理机到虚拟机_计算机软件及应用_IT/计算机_专业资料。...1.在 WIN-34KH84HVSMR, OS (WIN2008 R2 64bit ) 上安装 HYPER-V , 再...
Linux系统虚拟机迁移中的技术难点
原理参见前面的小节“V2V 内存迁移技术”。 VMware VMotion VMware 的在线迁移是...Microsoft Hyper-V 微软的 Hyper-V 从 2.0 开始支持了动态迁移技术。利用 ...
KVM虚拟机创建、管理及迁移技术
目前流行的虚拟化工 具如 VMware,Xen,HyperV,KVM 都提供了各自的迁移组件。...目前主流的在线迁移工具,如 VMwareVMotion 、 XEN 的 xenMotion 、 lib...
3.1 虚拟机的迁移
迁移虚拟机 一迁移虚拟机迁移是指将虚拟机从一个主机或存储位置移至另一个主机...·通过 vMotion 迁移(热迁移)前提条件是, 迁移的虚拟机数据存储位置必须是共享...
VMWare和Hyper-V的比较_图文
VMWareHyper-V的比较_IT/计算机_专业资料。微软 ...也有一些缺点,例如硬件需求的原因使得 VMotion 不起...MS Windows Hyper-V 2005 R2 VS VMware VI3:- ...
更多相关标签: