gOxiA=苏繁=SuFan Blog

Windows Server 2012 Hyper-V 复制

        早在去年11月份 gOxiA 就与大家分享了 Windows Server 2012 Hyper-V 虚拟机可移动性方面的几篇文章：“Windows Server 2012 使用 SMB 共享存储的实时迁移”、“Windows Server 2012 Hyper-V over SMB”、“详解 Windows Server 2012 无需共享存储的实时迁移”。这些功能和特性确实极大的方便了 ITPro，使大家能够轻松、快速、安全的对虚拟机进行迁移。当对这几部分的实时迁移有一定的学习和理解后，Hyper-V 复制就显得更加容易，所以之前也就没有再单独写这部分的文章。

        最近遇到几个案例都是探讨虚机备份和低成本的异地灾备的，而且这几天在做 Windows Server 2012 R2 Preview 到 RTM 迁移时也涉及到了 Hyper-V 复制，所以打算写篇东西出来跟大家分享分享，也算给自己留个存档。Hyper-V 复制，即：Hyper-V Replica，也称之为 Hyper-V 副本，是一种异步虚拟机复制技术，基于 HTTP 协议进行传输，所以它也非常适合应用在广域网环境中。在设计上，Hyper-V 复制主要用于商业连续性和灾难恢复场景。因为不需要任何共享存储，所以该技术可用于任何服务器、网络或存储供应商的设备。

        要为 Hyper-V 主机启用复制功能，首先确保当前主机已经加入到 AD，并参考无需共享存储的实时迁移对主机做 Kerberos 委派，添加“hyper-v replica service”，然后还要修改当前主机的 Hyper-V 设置，在“复制配置”下勾选“启用此计算机作为副本服务器”，并选择“使用 Kerberos (HTTP)”端口保持80默认，在“授权和存储”选项下，选择“允许从任何经过身份验证的服务器重进行服务”，并指定副本的默认存储位置。可参考下图设置：

        在完成上述设置后向导会提示防火墙设置的相关警告，我们只需要进入防火墙设置允许 Hyper-V 副本 HTTP 通过。

        接下来，便可选择一台虚机进行复制的配置，整个过程可以参考下面的截图。

选择虚拟机，启用复制。

指定副本服务器，填写服务器名称。

因为仅允许使用 Kerberos 身份验证(HTTP)，所以在连接参数向导中仅有一种可选模式，如果网络带宽比较紧张，建议勾选“压缩通过网络传输的数据”。

选择复制 VHD，是非常人性化的配置，比如当前虚机本身附加有备份用的磁盘，那么在做 Hyper-V Replica 时可以不对这些备份用VHD做复制，当然有些用户也可能仅是为了复制虚机的数据VHD而不需要系统盘，那么也可以在该步骤中进行选择。

根据需要配置复制频率，默认为每5分钟将更改发送到副本服务器。

在容灾级别不高而且对数据存储容量毕竟敏感的场景下，可以“仅保留最新恢复点”。

“选择初始复制方法”下，可以结合场景并根据实际情况进行选择。如果当前场景是局域网环境，并且此时网络带宽并不拥挤，那么可使用默认的“通过网络发送初始副本”作为初始复制方法，并“立即启动复制”。

        在完成初始复制后，Hyper-V 复制功能会按照之前设置计划的时间频率将虚拟机的变更发送出去。这些变更时通过日志文件追踪的，并且将在变更发往复制服务器前进行压缩。在主服务器上，变更会被保存在一个.hrl文件中，该文件与被复制的VHD文件位于相同位置下。

        Hyper-V 复制的故障转移操作有三个主要选项：

1. 计划内故障转移，顾名思义也就是按照预先确定的计划来进行故障转移。该方式需要满足两个前提条件：在初始故障转移前，虚拟机必须关闭；被复制主机必须也启用复制功能，并允许接收来自复制主机的复制。
   
2. 测试故障转移，在复制服务器上进行操作，允许在不中断当前持续的复制配置下，生成并启动一个新的用于测试用途的虚拟机。
   
3. 计划外故障转移，很容易理解了，被复制主机意外宕机时，我们便可以在复制主机上执行“故障转移”，将该虚机启动上线。
   

        玩转 Windows Server 2012 Hyper-V 的实时迁移和复制功能，并灵活应用在不同场景下，将会使 ITPro 感到无比轻松。

        参考：Hyper-V 副本概述、演示 Hyper-V 副本、Deploy Hyper-V Replica

在 Windows Server 2012 R2 RTM 和 Preview 之间迁移虚机将会失败

        Windows Server 2012 R2  RTM 在9月10日签约 MSDN/TechNet 向订阅用户发布，这次微软还是非常重视用户反馈的，最终选择提前向订阅用户发布 RTM。gOxiA 在第一时间下载了 Windows Server 2012 R2 RTM，并着手升级当前的 Windows Server 2012 R2 Preview 环境，两台基于 Windows Server 2012 R2 Preview 的 Hyper-V 主机，分别跑了一些虚机，因为服务器有 iDRAC，所以即使 gOxiA 没在办公室只需 VPN 到单位网络，通过 iDRAC 远程控制服务器，并通过 WDS 部署即可，非常方便！

        因为 Windows Server 2012 RTM 不支持从 Preview 版本进行就地升级，所以必须要全新安装，虽然目前 Hyper-V 可以直接导入磁盘上存储的虚拟机，但是为了保险起见还是利用无需共享存储的实时迁移将虚拟机暂时移动到了另一台 Hyper-V 上。之后全新的安装过程非常简单，因为是在千兆网环境下通过 WDS 进行部署的，所以整体的速度非常非常快。

        对新装的 Windows Server 2012 RTM 进行基础配置，加域等等的工作之后，便打算将之前跑在上面的虚拟机迁移回来，但是在实际操作时却遇到了问题，会提示无所进行迁移，因为接收到的虚拟机迁移数据无效或已损坏！由于之前忘记截图，所以 Hyper-V 管理器上的提示窗体截图没能保存下来，还好日志中有该问题的记录，提供出来给大家作为参考。

        由于错误提示非常简单，并没有更具体的信息，而且 Windows Server 2012 R2 RTM 刚刚发布，参考文章少之又少，所以只能自己一点一点摸索解决！回忆之前 Windows Server 2012 到 2012 R2 Preview 的升级，是基于本地的就地升级，所以也没发现有什么问题，但是隐约记得在升级完第一台服务器后，确实也执行过实时迁移操作，并没有遇到这次的问题，难道是我本身虚机数据出现了损坏？！检查了各虚机数据都是正常的，但迁移就是无法通过，无奈试试 Hyper-V 复制。即，在位于 Preview 版上的虚拟机配置 Hyper-V 副本，将配置和数据传输到 RTM 上。一试，还真成功了！为了不再耽误时间，所以决定将要升级的 Preview 服务器上的所以虚机都通过 Hyper-V 副本功能传输到 RTM 这台服务器上。在完成传输后，关闭这些虚机，并执行“计划的内故障转移”即可。

        当所有配置了 Hyper-V 副本的虚拟机都执行了计划内故障转移之后，相信 Preview 上所有的虚机都以完成了到 RTM 的迁移。现在只需再为这些虚机“删除复制”以禁用副本功能，便可开始进行 Windows Server 2012 RTM 的全新安装。

        当第二台 Windows Server 2012 R2 RTM 安装和配置完毕后，发现在两台服务器间的实时迁移恢复正常了，因此判断 Windows Server 2012 R2 RTM 与 Preview 的实时迁移应该存在兼容性问题，如果大家也在实际环境中遇到了这样的问题，不妨换种思路参考 gOxiA 的亲身经历来解决。

HOWTO : 激活 Windows 8 Enterprise RTM

        上一篇日志中 gOxiA 在第一时间与大家分享了 MSDN & TechNet 订阅发布 Windows 8 RTM，同时也迎来了最大规模的一次  Windows 8 RTM 安装潮，相信不少用户都会选择 Windows 8 Enterprise，毕竟在 Windows 8 SKUs 中，Enterprise（企业版）是功能最全、最强大的。但是，按照微软的销售策略 Windows 8 Enterprise 应该属于 SA 级别的批量授权产品，而此类产品通常是面向那些大批量采购并拥有软件保障服务的企业，如果你了解微软批量授权，就会知道产品密钥通常是 KMS 或 MAK 类型的，而正因为如此也就引出了今天的话题。

        通常我们在安装完 Windows 产品后，都会先去激活产品，但是在 Windows 8 Enterprise RTM 上，大部分用户可能在激活时都遇到了如截图中出现的错误，即：0x8007232B，告知 DNS 名称不存在。

        出现这个问题的原因，其实很简单！微软在进行 Windows 8 Enterprise RTM 封装时使用的是 KMS 激活，而 KMS 的显著特点就是客户端激活当前副本时需要连接到企业内部的 KMS 服务器进行认证，所以结果可想而知！

        现在回过头来看看我们所申请到的激活密钥，MAK 类型！OK，现在我们只需要将当前 Windows 8 Enterprise RTM 副本改为 MAK 激活即可，方法很简单！以管理员权限运行“命令提示符”（CMD），然后先键入下面的命令行，将指定的密钥（PS：这里可以用我们申请到的 MAK 类型密钥）安装到当前产品副本上。

        之后，再执行“slmgr /ato”进行激活，或者通过 UI 界面操作也可以。Windows 8 Enterprise RTM 与之前 Windows 7 不同，后者可以通过 UI 界面修改密钥，也许微软是在完善正版化所以才在 Windows 8 Enterprise RTM 上做了如此改动，当然也不排除这属于封装失误，没准过段时间会重新发布个 ISO 也说不定。

        看到不少朋友这两天都提到这个问题，还是有必要写个日志跟大家分享分享！
        补充：下午查了下资料，我们可以使用“SLUI 3”命令行来调用更改密钥的 UI 界面。