gOxiA=苏繁=SuFan Blog

Windows Server 2012 Hyper-V over SMB

        Windows Server 2012 Hyper-V over SMB，即：基于 SMB 的 Hyper-V，简单理解就是将 Hyper-V 的配置文件、虚拟磁盘（VHD）、快照等文件以共享文件存储的方式来进行存储和使用。要实现这一特性，需要使用 Windows Server 2012 的 SMB 3.0 文件共享作为 Hyper-V 的共享存储器。

        Hyper-V over SMB 的主要优势：

• 易于设置和管理，基于文件共享方式相比较专用的存储结构和LUN，更加容易设置和管理。  
• 较高的灵活性，Hyper-V over SMB 同样支持 Windows Server 2012 Hyper 的实时迁移技术。  
• 减少成本投资，因为无需专用存储，所以我们可以依靠 SMB 在现有的网络上为 Hyper-V 部署存储，不仅减少了在设备上投资，而且无需专门的存储知识。

        要部署 Hyper-V over SMB，我们必须了解其必备的条件！AD（Active Directory 活动目录）作为基础架构是必须的，但是 DC 不需要运行 Windows Server 2012 系统；Hyper-V 主机必须是 Windows Server 2012 系统；对于文件服务器，除了 Windows Server 2012 以外，还可以选择支持 SMB 3.0 协议的非 Microsoft 文件服务器。常见的部署方式有三种：

        主要区别就是 SMB 服务器的节点数量，对于测试和实验这类的非生产环境，我们可以使用单节点文件服务器的部署结构，对于要求高的则可以使用多节点或带有群集功能的文件服务器结构。在微软官方的手册中明确说明 Hyper-V over SMB 不支持回环配置，就是说不支持将 Hyper-V 主机节点用于存储服务器，但是在 gOxiA 测试“使用 SMB 共享存储的实时迁移”时还是仅使用了两台 Hyper-V 主机实现了 Hyper-V over SMB，不过也仅局限于测试，因为我们需要将共享存储的安全性降到最低，这样一来此种方式的部署则会显得没有任何意义，如果你当前的测试环境设备比较紧张，也可以尝试！只需要将共享目录的共享权限设置为：everyone 有完全控制的权限；同时目录安全性配置也配置为：everyone 有完全控制的权限。

        在开始 Hyper-V oever SMB 实践之前请再确认一下测试环境的准备情况，以 gOxiA 为例：一台 DC；两台 Hyper-V 主机，都加到 AD 并安装了文件共享服务。

        首先，使用 ADUC 创建两个组“HyperVHosts”和“HyperVAdmins”，将两台 Hyper-V 主机添加到“HyperVHosts”组，将用于管理 Hyper-V 的账号添加到“HyperVAdmins”，这样做是出于安全管理规范考虑，当然如果是测试环境，可以暂不考虑安全配置。

         然后，通过服务器管理器打开共享管理，并添加“SMB 共享 - 应用程序”类型的共享。

        在“共享位置”配置中，选择我们要存储虚拟机文件的卷，如：“E:”；“共享名称”设置中，在“共享名称”框中输入共享名，如：“SMB”，默认向导会在 E盘下自动创建一个 Share 目录，同时在其下创建 SMB 子目录，并将其设为共享，如：“hyper-vsmb”；“其他设置”选项中保持默认即可。

        之后进入权限设置，根据实际的情况，我们需要重新自定义权限，以确保 Hyper-V主机以及相关用户有适当的访问权限。

在“权限”选项中，首先禁用继承，并添加 Hyper-V 主机对该目录有完全控制权限，如下图所示：

        再切换到“共享”选项，添加 Hyper-V 主机和 Hyper-V 管理用户有完全控制的共享访问权限！注意：在两 Hyper-V 主机节点测试环境下，请将目录权限和共享权限都改为 everypne 有完全控制权限，否则在以后的 SMB 共享存储的实时迁移过程中会出现错误。

        完成 SMB 的设置后，我们便可以为 Hyper-V 主机上的虚机添加基于共享文件存储的虚拟磁盘（VHD），如下图所示：

        总结， Hyper-V over SMB 的配置操作其实非常简单，并没有特别需要设置的地方！只需牢记，文件服务器必须是支持 SMB 3.0 的文件服务器，如：Windows Server 2012；Hyper-V 主机必须是 Windows Server 2012 并加入到活动目录（AD），出于安全考虑可以单独创建安全组用于之后的权限分配。之所以要单独拿出来讲一讲，是便于学习下一篇“使用 SMB 共享存储的实时迁移”时，可以给 SMB 共享存储部分有一个参考！

        Hyper-V over SMB 部署的详细文档，可以参考：http://technet.microsoft.com/zh-cn/library/jj134187

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

        当我们在测试 Windows Server 2012 Hyper-V 实时迁移（如：无需共享存储的实时迁移）过程中可能会遇到 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”。”

        此外，还包含其他几个相关的 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 命令行，参考命令行如下：

        完成“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 命令手工注册来解决！

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

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

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

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

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

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