本站域名:http://goxia.maytide.net or http://sufan.maytide.net
移动设备请访问:http://goxia.maytide.net/m
转载文章,请务必保留出处与作者信息,未经许可严禁用于商业用途!
[WS2012] 差异磁盘在无需共享存储的实时迁移中的临时解决方案
在前一篇日志《详解 Windows Server 2012 无需共享存储的实时迁移》结尾中 gOxiA 提到差异磁盘在实施迁移中的问题,而本篇将简要与大家分享一下该问题的情况以及临时的解决方案。
如果在实时迁移场景中,要迁移的虚机磁盘使用了差异磁盘类型,那么在迁移过程中便会出现问题,具体的错误提示如下图所示:
“迁移目标上的虚拟机迁移操作失败。无法访问磁盘。”下面来看看这台虚机的磁盘配置情况,名为 XP 虚机的磁盘使用差异磁盘基于一个操作系统模板而创建,其父级磁盘存储位置位于其他分区目录,如下图所示:
当我们执行无需共享存储的实时迁移时,向导实际上只会迁移虚机“实体”文件,即:快照、分页、配置文件以及 VHD,而使用差异磁盘类型 VHD 的父级 VHD 不会被迁移,这可能是一个 Bug,之所以说是 Bug是因为在选择要移动的项目窗体中,迁移向导并未识别当前虚机的 VHD 是一个差异磁盘,所以也就无法检测到所涉及到的父级 VHD,但是实际上我们又可以通过提前手工复制父级 VHD 的手段来解决一些问题,使之能够完成正常的迁移。
不管结论如何,如果当前的实践环境使用了差异磁盘,那么请按照 gOxiA 提供的方案来解决!首先确认源主机上要迁移虚机的父级磁盘文件(VHD)存储路径,之后再目标主机同盘符下创建这个存储路径,并将父级磁盘文件(VHD)手工拷贝到目标主机对应位置,之后再去执行迁移即可顺利完成任务。
就是这么简单!反过来想想,其实在生产环境下,通常我们不会使用差异磁盘来部署虚机。但是大部分网友在进行实践时通常都会使用差异磁盘来减少对物理磁盘的占用,实践起来也确实方便。所以在目前未经微软方面证实并给出解决方案前,暂时可以使用 gOxiA 提供的方法来解决。
[WS2012] 详解 Windows Server 2012 无需共享存储的实时迁移
Windows Server 2012 无需共享存储的实时迁移
在 Windows Server 2012(WS2012)中微软提供了其最新的虚拟化平台 - Hyper-V 3.0,依靠 WS2012 最新的 SMB(Server Message Block)协议实现了透明迁移,也就是我们常说的实时迁移,这意味着我们能够在不中断虚机运行的情况下对其进行迁移。虽然这个技术之前就能够实现,但是我们需要为之付出高昂的成本,在过去为了实现迁移我们不得不购买专用的共享存储设备,而现在 Windows Server 2012 在虚机的可移动性方面做出了重大的改进。我们不必再依靠共享存储设备来实现实时迁移。
Windows Server 2012 也为我们提供了非常具有弹性和灵活性的选择,依靠 Windows Server 2012 目前能够实现的四个实时迁移方案:
- 无需共享存储的实时迁移
- 使用SMB 共享存储的实时迁移
- 存储环境下的迁移
- 故障转移群集中的实时迁移
而今天 gOxiA 将引领大家实践无需共享存储的实时迁移,相信大家一定会有不小的收获。顾名思义,无需共享存储的实时迁移使得我们能够在多台域成员的 Hyper-V 主机之间直接移动其虚拟机,且无需中断运行着的虚拟机。
这一操作的基本过程,将使用 SMB 实现对虚拟机 VHD 等文件的实时迁移工作,将被迁移的虚拟机 VHD 文件镜像以及快照等文件同步到目标主机(Hyper-V),而迁移过程的连接管理依靠 VMMS(Virtual Machine Management Service)进行。当 VHD 等文件在两端同步完毕后,才会开始实时迁移的后续步骤,首先虚机的状态信息会从源主机迁移到目标主机,之后中断两端文件的同步关系,并删除源主机上的文件存储,最后关闭实施迁移连接完毕迁移工作。
无需共享存储的实时迁移还具备以下四个特性:
- 即使在迁移工程中遇到故障或问题,导致迁移失败,那么总能保证有一台可用虚机。
- 可跨群集迁移虚机,例如我们可以从非群集的计算机迁移到群集计算机。
- 支持不同存储类型的迁移虚拟机,无需受存储类型约束,不管环境是 JBOD 还是直通存储,又或者是 iSCSI 存储,都能实现实时迁移。
- 可以使用 Powershell 发起实施迁移的操作,那么就能够实现自动化的操作。
综上所述,无需共享存储的实时迁移为我们提供了低成本,高效率,灵活便捷的迁移方案,我们利用这一功能特性能够适用到多种应用环境下。例如:
- 开发或 IT 人员能够将测试好的虚机在不停机的前提下直接迁移到生产环境。
- 在多主机环境下,如果需要进行主机维护,可以在不依赖共享存储的前提下,快速、灵活的在主机之间移动虚机。
- 故障检修和硬件升级,中小企业可能只有一台服务器并通过虚拟化方式运行着业务服务器,当遇到硬件故障或需要更新服务器时,IT顾问可以快速的在笔记本上建立临时的基于 Windows Server 2012 的 Hyper-V 主机,将其加入到现有域中完成业务虚机的迁移,在完成原服务器的更换后,再迁移回去。
利用无需共享存储的实时迁移技术,能够应对很多场景的应用,而接下来 gOxiA 将引领大家进行实践演练,首先准备好两台基于 Windows Server 2012 的 Hyper-V 主机,并将其加入到现有活动目录(AD域)中,这一步是必须的。然后,在其中一台主机上创建一个虚机用于迁移实践。以 gOxiA 环境为例,使用两台设备:Dell T310(Intel Xeon X3470)、Thinkpad T420(Intel i7-2620m),安装 WS2012 启用 Hyper-V,并加入到公司活动目录(AD域),在 HV3 上创建一个 XP 虚拟机,局域网是一个千兆网络。
准备就绪后首先需要对两台虚机进行配置,启用迁移功能,为此打开 Hyper-V 管理器,选中要操作的主机,点击鼠标右键选择”设置“,在”实施迁移“选项中勾选”启用传入和传出的实时迁移“,身份验证协议选择”使用 Kerberos“,”并行实时迁移“设置保持默认,因为是测试,所以”传入的实时迁移“可以选择”使用任何可用的网络进行实时迁移“。
完成这些设置后我们便可以开始执行迁移工作了,可能有朋友会问:“为什么没有按照网上其他的教程去做权限委派?岂不是会迁移失败?!”,事实是这样吗?!gOxiA 会在文末与大家分享这一知识!首先还是开始我们的迁移步骤,首先登录到 XP 虚机所在的 Hyper-V 主机(HV3),打开 Hyper-V 管理器选中 XP 虚机,在右边“操作”窗体点击“移动…”启动迁移向导,并在向导首页点击“下一步”。
在“指定目标计算机”向导页的名称框中键入虚机迁移的目标主机名称,本环境下为“Hyper-V”,当然也可以通过“浏览”进行确认选择。
“移动选项”下默认选择“将虚拟机的数据移动到一个位置”,并点击“下一步”。如果你希望将配置文件、分页文件或快照存储到目标主机的不同位置,则可以选择“通过选择项目移动位置来移动虚拟机的数据”;而“仅移动虚拟机”则适用于“使用了 SMB 共享存储”的环境。
之后会弹出目标主机的资源管理窗体,便于我们选择和确定目标的存储位置。
完成上面的步骤离成功就接近一半了,确认各选项设置后点击“完成”开始迁移,如下图所示:
接下来的过程会出现错误(PS:不是权限委派方面的错误,大家别急!),“无法将虚拟机移动到目标计算机。目标计算机上的硬件与此虚拟机的硬件要求不兼容”,具体的提示时说:“虚拟机正在使用物理计算机 Hyper-V 上不受支持的特定于处理器的功能。”回顾一下前面的文字,是否注意到了 gOxiA 对实践环境下的计算机处理器进行了醒目的标注!微软虚拟化实时迁移技术目前不支持在不同厂商的处理器之间进行虚机的迁移。但是,支持同厂商不同版本处理器的实时迁移。所以前面提到的硬件兼容性错误可以在虚机的配置上进行设置解决。为此,选中虚机进入其属性设置,在右边窗体中找到“处理器”并展开选项进入“兼容性”设置,复选“迁移到具有不同处理器版本的物理计算机”。完成该操作后即可解决处理器兼容性问题,我们可以重新开始进行迁移操作。
在迁移过程中我们还会遇到一个问题(PS:别急,还不是权限委派的事儿!哈哈),迁移向导会可能会提示我们在目标主机上无法找到该虚拟机的网络连接,即:“虚拟交换机”。这个问题比较常见,因为我们可能并未在所有的 Hyper-V 主机上对虚拟交换机进行名称的规划,固然在迁移配置文件时,无法验证虚机的网络连接是否存在于目标主机,但是迁移向导为我们提供了解决此问题的步骤,可以重新为虚机指定目标主机上已经存在的虚机交换机,也就是我们常说的虚拟网卡,虽然进行了重新的指定设置,但虚机之前的 MAC 地址会得到保留,这也是保证透明迁移的前提!
最后确认迁移选项,点击“完成”并开始执行迁移!
整个的迁移过程所消耗的时间取决被迁移的虚机大小以及网络带宽和服务器的磁盘 I/O 性能,在 gOxiA 的千兆网络环境中,基于 SATA 磁盘进行的迁移,耗去了几分钟的时间,完全在合理的接受范围内!整个迁移过程确实没有中断虚机的运行,实践中 gOxiA 分别用 Ping 和网络拷贝进行了测试,均没有出现异常。
Windows Server 2012 无需共享存储的实时迁移整体来讲非常易用,无需过多的复杂设置即可完成,仔细看看也就是几个简单的步骤,这完全依靠强大的基础架构作为支撑,所以 AD 是必须的!
现在我们来谈谈权限委派问题!网上有文章提到 Windows Server 2012 无需共享存储的实时迁移不支持双向操作,简单讲就是在 A 主机上通过 Hyper-V 管理器去连接 B 主机并将 B 主机的虚机迁移到 A 主机上,当默认设置时这样操作肯定会失败!因为 Kerberos 验证协议默认情况下,Hyper-V 主机只信任从本机发起的迁移,简单理解就是只将自己主机上的资源主动搬到其他主机上,反之就要对权限进行委派!否则就会出现如下图所示的常见错误!
“迁移源上的虚拟机迁移操作失败”,具体信息是“无法与主机 Hyper-V 建立连接:安全包中没有可用的凭证(0x8009030E)。”当出现这个错误提示时,一定是用户在 A 主机上通过 Hyper-V 管理器去迁移 B 主机上的虚机,且没有设置权限委派。所以,为了避免此类情况的发生,并在符合安规的前提下可以为 Hyper-V 主机设置权限委派。为此,打开 ADUC 找到 Hyper-V 主机,进入其属性的”委派“选项卡, 选择”仅信任此计算机来委派指定的服务“,并为子项选择”仅使用 Kerberos“,并添加两个服务类型”CIFS“和”Microsoft Virtual System Migration Service“,前者就是代表 SMB,后者则是所需的 VMMS 服务模块。”用户或计算机“则设置为对端的主机名称。
完成上面的权限委派设置后,便可以在当前主机上去操作对端或其他主机执行迁移任务(被动迁移)。当然会有网友会问“既然发起虚机迁移需要本机信任,那么迁移的目标主机如何限制或信任发起迁移的源主机呢?!”简单说就是允许哪些源主机将虚机迁移到本机?!其实这个问题前面的介绍就有提到,即: Hyper-V 主机属性里“实时迁移”设置下的“传入的实时迁移”选项,在这里我们可以指定本机接受哪个网络或 IP 发起的迁移。
为确保无需共享存储的实时迁移得以顺利的进行,gOxiA 做一下总结:
- Hyper-V 主机必须是 Windows Server 2012 系统。
- Hyper-V 主机必须加入到 AD。
- Hyper-V 主机处理器(CPU)必须为同一厂家,但允许使用不同的版本。
- 如需执行被动迁移,必须为源主机配置权限委派。
OK!到这里相信大家已经对 Windows Server 2012 无需共享存储的实时迁移有了深刻和正确的认识,并解开了心中的疑问!现在感兴趣的网友便可以正确、顺利的开始进行实践,祝君好运!
最后的友情提示(PS:gOxiA 没完没了了,呵呵!)很重要!Windows Server 2012 无需共享存储的实时迁移技术,能够迁移使用差异磁盘的虚机,但目前貌似并未得到完美的支持,可能属于 Bug 问题!gOxiA 会单独撰写一篇文章与大家简要分享一下如何确保使用差异磁盘的虚机完成迁移任务。而剩下的几种实时迁移技术,会在今后与大家进行分享!
[MDT] P2V Migration for Software Assurance 应用篇
P2V Migration for Software Assurance 应用篇
距离之前发布的几篇有关 P2V Migration for Software Assurance(以下简称:P2V Migration for SA)的文章已过去2个月左右的时间,gOxiA 说太忙没时间写也都是托词,其实更多时候感觉是精力有限!就在最近,P2V Migration for SA 正式版发布了!而面对更多用户开始部署 Windows 7 的大好局面,P2V Migration for SA 正式版的出现,能够帮助到更多用户轻松的部署到 Windows 7。
P2V Migration for SA 的功能及实现的最终目标并不难理解,利用 P2V Migration for SA 我们能够在部署到 Windows 7 时将之前的旧系统转换为 Windows Virtual PC 下的虚拟机,这样一来即使我们已经被部署到 Windows 7 环境,但是利用 XP Mode 特性仍能够轻松、便捷地使用我们旧系统环境中的应用软件和设置。P2V Migration for SA 的整个执行过程看似都是那么简单便捷,这一切都要感谢 Microsoft Deployment Toolkit Team,而他们为广大用户所带来的一整套部署解决方案还是免费的!
正如我前面所讲的 P2V Migration for SA 在使用起来非常简单,与常规的安装工作序列并无太大区别,唯一加入的就是将现有的系统捕获为虚拟机,在安装完 Windows 7 系统后自动执行 Windows Virtual PC 的安装,并将虚拟机配置到当前环境中。在开始介绍 P2V Migration for SA 的应用前,大家先回顾一下 gOxiA 之前的文章:
当我们安装好 P2V Migration for SA 后,在 Task Sequences 新建任务序列中看到新添加的三个任务序列,分别是:Standard Client Task Sequence with P2V Migration、Standard Client Replace Task Sequence with P2V Migration 以及 Custom Task Sequence with P2V Migration。
其中 Standard Client Task Sequence with P2V Migration 便是我们常用的任务序列。gOxiA 事先准备了一个测试环境,在 MDT 中导入了 Windows 7 的安装源,并跟随向导创建了一个基于 Standard Client Task Sequence with P2V Migration 类型的任务序列,之后在一台虚拟机上开始进行实验,此台虚拟机已经安装了 Windows 7 Ultimate 中文版(PS:虽然不是 Windows XP,但不影响整体的测试效果!)整个过程中初期部分与常规的 MDT 部署客户端没有太大区别,除了在过程中捕获当前系统会消耗一段时间。在当先系统环境中执行 Litetouch.vbs,选择之前创建的 P2V Migration for SA 任务序列,跟随向导完成操作后,剩下的就交给 MDT 和 P2V Migration for SA 了!我们可以稍作休息,在系统完成安装之后,我们会看到后续执行的任务发生了变化。
如上图所示,P2V Migtation for SA 开始将之前捕获的系统虚拟磁盘文件恢复到当前的系统之上。而在这一过程前面,会自动为当前系统安装 Windows Virtual PC 以及 without VT 的补丁。
最后整个任务序列完成之后我们便能够在 Windows 7 开始菜单的所有程序中看到 Windows Virtual PC 以及类似名为“Old OS – Administrator”的旧系统的虚拟机,并且其状态为运行中。我们可以即刻访问这个虚拟机来使用我们的旧系统环境!
P2V Migration for SA 无疑为我们部署 Windows 7 并保留旧系统提供了便捷的解决方案,如果你正考虑将现有客户端计算机部署到 Windows 7,并希望用户能够继续使用旧系统环境,P2V Migration for SA 将满足你的需要!