欢迎光临,这里是 gOxiA=苏繁=SuFan 独立的个人博客。
本站域名:http://goxia.maytide.net or http://sufan.maytide.net
移动设备请访问:http://goxia.maytide.net/m
转载文章,请务必保留出处与作者信息,未经许可严禁用于商业用途!

logo_winserver2012

HOWTO: 解决 Windows Server 2012 Hyper-V 实时迁移时遇到的 0x80090303 故障

        当我们在测试 Windows Server 2012 Hyper-V 实时迁移(如:无需共享存储的实时迁移)过程中可能会遇到 0x80090303 故障,错误如下图所示:

0x80090303

        具体内容大致为“迁移源上的虚拟机迁移操作失败。无法验证源主机上的连接:指定的目标未知或无法达到(0x80090303)。”由于 0x80090303 故障与之前日志中提到的 0x8009030E 故障极为相似,如果不加注意我们便会按照实时迁移时 kerberos 权限委派的步骤进行排错解决,去为主机委派设置添加“Microsoft Virtual System Migration Service”服务类型。gOxiA 当初就走入了这个误区,当使用 ADUC 为 Hyper-V 主机去做委派时发现在主机委派服务类型中并未找到“Microsoft Virtual System Migration Service”。

        检查 Hyper-V 主机事件日志发现在“应用程序和服务日志”-“Microsoft”-“Windows”-“Hyper-V-VMMS”-“Admin”下记录有错误的事件ID:14050,来源为:Hyper-V-VMMS。具体内容是“无法注册服务主体名称“Microsoft Virtual System Migration Service”。”

image

        此外,还包含其他几个相关的 SPN(服务主体名称)错误日志:“Hyper-V Replica Service”、“Microsoft Virtual Console Service”。之后使用 setspn –l hostname 进行检查,发现当前主机确实缺少这些 SPN,而“Microsoft Virtual System Migration Service”是我们迁移虚机所必须的。

        那么什么是 SPN 呢?!引用一篇微软官方 Blog 的解释:SPN 即“服务主体名称”,是一种名称,唯一标识一个服务实例。用来验证 Kerberos 身份验证的 SPN 的必须正确设置。SPN 是 Active Birectory 属性,但不暴露在 AD 的管理单元。那么 SPN 的作用是什么呢?!gOxiA 推荐这篇微软 Blog http://blogs.technet.com/b/crmchina/archive/2010/01/29/crm-spn.aspx 供大家参考,虽然与 Hyper-V 没有直接关系,但他们之间的概念是相通的,便于我们更好的理解该故障发生的原因。

        要解决该实时迁移过程中遇到的 0x80090303 故障,我们只需要手工在 Hyper-V 主机上对“Microsoft Virtual System Migration Service”进行 SPN 注册即可。为此,我们需要用到 setspn –s spnname/hostname(and FQDN) NetBIOSName 命令行,参考命令行如下:

setspn –s “microsoft virtual system migration service/hv3”hv3

setspn –s “microsoft virtual system migration service/hv3.contoso.com”hv3

        完成“Microsoft Virtual System Migration Service”的 SPN 注册后,我们便可以正常执行实时迁移,0x80090303 故障消失!按理说 SPN 的注册应该是自动的,但是为什么在 gOxiA 的实验环境下出现失败注册,可能跟 DC 是 SBS2011 有关,因为网上能找到类似的故障都是使用的 SBS2011 作为域控。当然也不排除其他可能存在的因素,在微软的 KB2761899 中就提及到了这个事件 ID,如果你也遇到这个问题,并排除 SBS2011 的原因,那么可以参考:http://support.microsoft.com/kb/2761899?wa=wsignin1.0 解决!

        关于 SPN 自动注册失败的原因及解决办法,gOxiA 会继续关注,一有答案便会跟大家分享!目前的办法只有使用 setspn 命令手工注册来解决!

logo_winserver2012

        在前一篇日志《详解 Windows Server 2012 无需共享存储的实时迁移》结尾中 gOxiA 提到差异磁盘在实施迁移中的问题,而本篇将简要与大家分享一下该问题的情况以及临时的解决方案。

        如果在实时迁移场景中,要迁移的虚机磁盘使用了差异磁盘类型,那么在迁移过程中便会出现问题,具体的错误提示如下图所示:

15

        “迁移目标上的虚拟机迁移操作失败。无法访问磁盘。”下面来看看这台虚机的磁盘配置情况,名为 XP 虚机的磁盘使用差异磁盘基于一个操作系统模板而创建,其父级磁盘存储位置位于其他分区目录,如下图所示:

image

        当我们执行无需共享存储的实时迁移时,向导实际上只会迁移虚机“实体”文件,即:快照、分页、配置文件以及 VHD,而使用差异磁盘类型 VHD 的父级 VHD 不会被迁移,这可能是一个 Bug,之所以说是 Bug是因为在选择要移动的项目窗体中,迁移向导并未识别当前虚机的 VHD 是一个差异磁盘,所以也就无法检测到所涉及到的父级 VHD,但是实际上我们又可以通过提前手工复制父级 VHD 的手段来解决一些问题,使之能够完成正常的迁移。

image

        不管结论如何,如果当前的实践环境使用了差异磁盘,那么请按照 gOxiA  提供的方案来解决!首先确认源主机上要迁移虚机的父级磁盘文件(VHD)存储路径,之后再目标主机同盘符下创建这个存储路径,并将父级磁盘文件(VHD)手工拷贝到目标主机对应位置,之后再去执行迁移即可顺利完成任务。

        就是这么简单!反过来想想,其实在生产环境下,通常我们不会使用差异磁盘来部署虚机。但是大部分网友在进行实践时通常都会使用差异磁盘来减少对物理磁盘的占用,实践起来也确实方便。所以在目前未经微软方面证实并给出解决方案前,暂时可以使用 gOxiA 提供的方法来解决。

logo_winserver2012

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 主机之间直接移动其虚拟机,且无需中断运行着的虚拟机。

shared_nothing_live_migration

        这一操作的基本过程,将使用 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 虚拟机,局域网是一个千兆网络。

image

        准备就绪后首先需要对两台虚机进行配置,启用迁移功能,为此打开 Hyper-V 管理器,选中要操作的主机,点击鼠标右键选择”设置“,在”实施迁移“选项中勾选”启用传入和传出的实时迁移“,身份验证协议选择”使用 Kerberos“,”并行实时迁移“设置保持默认,因为是测试,所以”传入的实时迁移“可以选择”使用任何可用的网络进行实时迁移“。

2

        完成这些设置后我们便可以开始执行迁移工作了,可能有朋友会问:“为什么没有按照网上其他的教程去做权限委派?岂不是会迁移失败?!”,事实是这样吗?!gOxiA 会在文末与大家分享这一知识!首先还是开始我们的迁移步骤,首先登录到 XP 虚机所在的 Hyper-V 主机(HV3),打开 Hyper-V 管理器选中 XP 虚机,在右边“操作”窗体点击“移动…”启动迁移向导,并在向导首页点击“下一步”。

3

        在“指定目标计算机”向导页的名称框中键入虚机迁移的目标主机名称,本环境下为“Hyper-V”,当然也可以通过“浏览”进行确认选择。

4

        “移动选项”下默认选择“将虚拟机的数据移动到一个位置”,并点击“下一步”。如果你希望将配置文件、分页文件或快照存储到目标主机的不同位置,则可以选择“通过选择项目移动位置来移动虚拟机的数据”;而“仅移动虚拟机”则适用于“使用了 SMB 共享存储”的环境。

5

        之后会弹出目标主机的资源管理窗体,便于我们选择和确定目标的存储位置。

6

        完成上面的步骤离成功就接近一半了,确认各选项设置后点击“完成”开始迁移,如下图所示:

7

        接下来的过程会出现错误(PS:不是权限委派方面的错误,大家别急!),“无法将虚拟机移动到目标计算机。目标计算机上的硬件与此虚拟机的硬件要求不兼容”,具体的提示时说:“虚拟机正在使用物理计算机 Hyper-V 上不受支持的特定于处理器的功能。”回顾一下前面的文字,是否注意到了 gOxiA 对实践环境下的计算机处理器进行了醒目的标注!微软虚拟化实时迁移技术目前不支持在不同厂商的处理器之间进行虚机的迁移。但是,支持同厂商不同版本处理器的实时迁移。所以前面提到的硬件兼容性错误可以在虚机的配置上进行设置解决。为此,选中虚机进入其属性设置,在右边窗体中找到“处理器”并展开选项进入“兼容性”设置,复选“迁移到具有不同处理器版本的物理计算机”。完成该操作后即可解决处理器兼容性问题,我们可以重新开始进行迁移操作。

8

9

        在迁移过程中我们还会遇到一个问题(PS:别急,还不是权限委派的事儿!哈哈),迁移向导会可能会提示我们在目标主机上无法找到该虚拟机的网络连接,即:“虚拟交换机”。这个问题比较常见,因为我们可能并未在所有的 Hyper-V 主机上对虚拟交换机进行名称的规划,固然在迁移配置文件时,无法验证虚机的网络连接是否存在于目标主机,但是迁移向导为我们提供了解决此问题的步骤,可以重新为虚机指定目标主机上已经存在的虚机交换机,也就是我们常说的虚拟网卡,虽然进行了重新的指定设置,但虚机之前的 MAC 地址会得到保留,这也是保证透明迁移的前提!

10

        最后确认迁移选项,点击“完成”并开始执行迁移!

11

        整个的迁移过程所消耗的时间取决被迁移的虚机大小以及网络带宽和服务器的磁盘 I/O 性能,在 gOxiA 的千兆网络环境中,基于 SATA 磁盘进行的迁移,耗去了几分钟的时间,完全在合理的接受范围内!整个迁移过程确实没有中断虚机的运行,实践中 gOxiA 分别用 Ping 和网络拷贝进行了测试,均没有出现异常。

14

        Windows Server 2012 无需共享存储的实时迁移整体来讲非常易用,无需过多的复杂设置即可完成,仔细看看也就是几个简单的步骤,这完全依靠强大的基础架构作为支撑,所以 AD 是必须的!

        现在我们来谈谈权限委派问题!网上有文章提到 Windows Server 2012 无需共享存储的实时迁移不支持双向操作,简单讲就是在 A 主机上通过 Hyper-V 管理器去连接 B 主机并将 B 主机的虚机迁移到 A 主机上,当默认设置时这样操作肯定会失败!因为 Kerberos 验证协议默认情况下,Hyper-V 主机只信任从本机发起的迁移,简单理解就是只将自己主机上的资源主动搬到其他主机上,反之就要对权限进行委派!否则就会出现如下图所示的常见错误!

0x8009030E

        “迁移源上的虚拟机迁移操作失败”,具体信息是“无法与主机 Hyper-V 建立连接:安全包中没有可用的凭证(0x8009030E)。”当出现这个错误提示时,一定是用户在 A 主机上通过 Hyper-V 管理器去迁移 B 主机上的虚机,且没有设置权限委派。所以,为了避免此类情况的发生,并在符合安规的前提下可以为 Hyper-V 主机设置权限委派。为此,打开 ADUC 找到 Hyper-V 主机,进入其属性的”委派“选项卡, 选择”仅信任此计算机来委派指定的服务“,并为子项选择”仅使用 Kerberos“,并添加两个服务类型”CIFS“和”Microsoft Virtual System Migration Service“,前者就是代表 SMB,后者则是所需的 VMMS 服务模块。”用户或计算机“则设置为对端的主机名称。

image

        完成上面的权限委派设置后,便可以在当前主机上去操作对端或其他主机执行迁移任务(被动迁移)。当然会有网友会问“既然发起虚机迁移需要本机信任,那么迁移的目标主机如何限制或信任发起迁移的源主机呢?!”简单说就是允许哪些源主机将虚机迁移到本机?!其实这个问题前面的介绍就有提到,即: Hyper-V 主机属性里“实时迁移”设置下的“传入的实时迁移”选项,在这里我们可以指定本机接受哪个网络或 IP 发起的迁移。

image

        为确保无需共享存储的实时迁移得以顺利的进行,gOxiA 做一下总结:

  • Hyper-V 主机必须是 Windows Server 2012 系统。
  • Hyper-V 主机必须加入到 AD。
  • Hyper-V 主机处理器(CPU)必须为同一厂家,但允许使用不同的版本。
  • 如需执行被动迁移,必须为源主机配置权限委派。
    

        OK!到这里相信大家已经对 Windows Server 2012 无需共享存储的实时迁移有了深刻和正确的认识,并解开了心中的疑问!现在感兴趣的网友便可以正确、顺利的开始进行实践,祝君好运!

        最后的友情提示(PS:gOxiA 没完没了了,呵呵!)很重要!Windows Server 2012 无需共享存储的实时迁移技术,能够迁移使用差异磁盘的虚机,但目前貌似并未得到完美的支持,可能属于 Bug 问题!gOxiA 会单独撰写一篇文章与大家简要分享一下如何确保使用差异磁盘的虚机完成迁移任务。而剩下的几种实时迁移技术,会在今后与大家进行分享!

分页: 1/1 第一页 1 最后页 [ 显示模式: 摘要 | 列表 ]