如何将windows server 2008 hyperv迁移到2016

通过 Hyper-V，可以使用 Windows 中的一项技术创建一个虚拟化的服务器计算环境。 本指南提供有关将 Hyper-V 角色（包括虚拟机、数据和操作系统设置）从在早期版本 Windows 中运行 Hyper-V 的源服务器迁移到运行 Windows Server® 2012 操作系统的目标服务器的信息和说明。

关于本指南

注意

你的详细反馈非常重要，可帮助我们使 Windows Server 迁移指南尽可能地可靠、完整和易于使用。 请花几分钟时间给本主题评分，并填写你给出此分数的原因。 如果你在 Lightweight View 中查看本主题，请单击该页面顶部的“给本主题评分”。 在经典视图中，单击页面右上角的星号（1=差，5=优）。 描述你喜欢的内容、不喜欢的内容或希望在本主题的将来版本中看到的内容。 若要提交有关如何改进迁移指南或实用工具的其他建议，请将其发布在 Windows Server 迁移论坛上。

本指南介绍如何迁移 Hyper-V 角色，并提供了相应的准备、迁移和验证步骤。

迁移文档和工具简化了将服务器角色设置和数据从现有服务器迁移到运行 Windows Server 2012 的目标服务器这一过程。 通过使用本指南中介绍的工具，你可以简化迁移过程，减少迁移时间，提高迁移过程的准确性，并帮助消除在迁移过程中可能出现的冲突。 有关如何在源服务器和目标服务器上安装和使用迁移工具的详细信息，请参阅 Windows Server 迁移工具安装、访问和删除指南。

目标受众

本文档适用于负责在托管环境中操作和部署 Hyper-V 的信息技术 (IT) 专业人员。

本指南未提供的内容

本指南不涵盖以下项目，原因是迁移工具不支持这些项目：

此迁移过程不支持群集方案。 有关如何在群集环境中进行迁移的信息，请参阅《将群集服务和应用程序迁移到 Windows Server 2012 循序渐进指南》将群集服务和应用程序迁移到 Windows Server 2012。

如何在同一计算机上升级角色不属于本指南的范围。

一次迁移多个服务器角色。

将 Hyper-V 从一台运行 Windows Server 2012 的服务器迁移到另一台运行 Windows Server 2012 的服务器。 几种新的 Hyper-V 管理工具和功能反倒支持该过程。 一般过程包括以下步骤：

确定是使用导出和导入还是实时迁移来移动虚拟机。 导出和导入可以用于工作组或域环境中，但是需要关闭虚拟机。 实时迁移需要域环境以及一些配置，但是可让你移动正在运行的虚拟机。

将 Hyper-V 角色添加到目标服务器。 添加此角色时，可以配置默认存储位置和实时迁移。 有关说明，请参阅安装 Hyper-V 并创建虚拟机。

在目标服务器上配置虚拟交换机和其他网络功能（可选）。 管理工具包括 Hyper-V 模块中的 cmdlet New-VMSwitch 和 Set-VMSwitch，以及 Hyper-V 管理器管理单元中的虚拟交换机管理器。

通过导出和导入或者通过进行实时迁移来移动虚拟机。 管理工具包括 cmdlet Export-VM 和 Import-VM，以及 Hyper-V 管理器中的菜单命令“导出”、“导入”和“移动”。 有关使用实时迁移来移动虚拟机的详细信息，请参阅在非集群虚拟机上配置和使用实时迁移。

有关 Hyper-V 模块中包含的 cmdlet 列表，请参阅 http://technetmicrosoftcom/library/hh848559。

支持的迁移方案

本指南为你提供了将在早期版本 Windows Server 中运行 Hyper-V 角色的现有服务器迁移到运行 Windows Server 2012 的服务器的说明。 本指南不包含有关在源服务器运行多个角色时进行迁移的说明。 如果你的服务器运行了多个角色，建议你根据其他角色迁移指南中提供的信息设计特定于你的服务器环境的自定义迁移过程。 Windows Server 迁移门户中提供了适用于其他角色的迁移指南。

小心

如果你的源服务器正在运行多个角色，则本指南中的某些迁移步骤（例如，用于计算机名称和 IP 配置的步骤）可导致在源服务器上运行的其他角色失败。

支持的操作系统

源服务器处理器

源服务器操作系统

目标服务器操作系统

目标服务器处理器

基于 x64

Windows Server 2008 Service Pack 2，仅限完全安装选项

Windows Server 2012，完全安装选项和服务器核心安装选项

基于 x64

基于 x64

Windows Server 2008 R2

Windows Server 2012，完全安装选项和服务器核心安装选项

基于 x64

基于 x64

的服务器核心安装选项 Windows Server 2008 R2

Windows Server 2012，完全安装选项和服务器核心安装选项

基于 x64

上表中显示的操作系统版本是所支持的操作系统和 Service Pack 的最旧组合。 支持较新的 Service Pack（如果有）。 未列出的操作系统将不受支持。 不支持作为独立产品的 Microsoft Hyper-V Server。

支持将运行 Hyper-V 的标准版、企业版和数据中心版的 Windows Server 作为源服务器或目标服务器。

不支持从源服务器迁移到运行与源服务器不同的系统 UI 语言（即已安装语言）的操作系统的目标服务器。 例如，无法使用 Windows Server 迁移工具从正使用法语系统 UI 语言运行 Windows Server 2008 的计算机将角色、操作系统设置、数据或共享迁移到正使用德语系统 UI 语言运行 Windows Server 2012 的计算机。

注意

系统 UI 语言是用于设置 Windows 操作系统的本地化安装程序包的语言。

支持的角色配置和设置

本节标识了可通过使用迁移工具迁移的配置和设置，以及必须手动迁移的配置和设置。 下表中进行了总结。

配置和设置

迁移类型

虚拟机（配置和数据）

自动（下面另有注明的除外）

Hyper-V 设置

自动

管理操作系统中的虚拟网络适配器设置

自动

外部虚拟网络

部分自动（参见下面的说明）

虚拟机队列 (VMQ) 网络设置

自动

自定义的远程管理设置

Manual

可以自动迁移以下配置和设置：

大多数虚拟机配置。 作为迁移的一部分移动虚拟机及其数据，但有些配置需要手动干预，如下所述。

Hyper-V 设置。 其中包括系统级设置和授权存储。

注意

如果从运行 Windows Server 2008 R2 的源服务器中进行迁移并且已设置 MAC 地址范围，则还将该值自动迁移到目标服务器。

内部和专用虚拟网络。

管理操作系统中的虚拟网络适配器设置。 当 Hyper-V 配置为使用物理网络适配器作为虚拟机可用于访问物理网络的桥时，将在运行 Hyper-V 角色的管理操作系统中创建虚拟网络适配器。 对于此虚拟网络适配器，迁移过程自动迁移此虚拟网络适配器的 IP 设置、绑定和 MAC 地址。 但是，必须手动重新建立虚拟网络适配器与物理网络适配器之间的连接，如迁移步骤中所述。

虚拟机队列 (VMQ) 网络设置。

在使用迁移工具之后，以下配置和设置需要手动干预：

防火墙设置。 在目标服务器上使用随 Hyper-V 一起安装的默认值重新创建防火墙设置。 如果已从这些默认值修改任何防火墙设置，则将需要在目标服务器上进行相同修改。

外部虚拟网络。 迁移工具在目标服务器上重新创建虚拟网络，但重新创建外部虚拟网络作为内部虚拟网络。 你将需要修改其中的每个网络，以将其连接到目标服务器上适当的物理网络适配器，如迁移步骤中所述。

VFD 和 ISO 文件。 不会迁移这些文件，因为它们不是运行虚拟机所必需的，而且它们不受 Import 和 Export cmdlet 支持。 若要使这些文件可供迁移后的虚拟机使用，请将这些文件手动复制到目标服务器，然后在迁移虚拟机之后将它们重新附加到虚拟机。

直接连接到虚拟机的物理磁盘的连接。 不会迁移这些连接（有时称为“传递磁盘”），因为磁盘引用在目标服务器上可能无效。 若要使某个物理磁盘可供迁移后的虚拟机使用，请将该磁盘连接到目标服务器，然后在迁移虚拟机之后将该磁盘连接到虚拟机，如迁移步骤中所述。

自定义的远程管理设置。 如果已自定义 Hyper-V 以进行远程访问，你将需要执行一些其他过程来重新创建 DCOM 和 WMI 命名空间设置。 迁移步骤标识应执行这些过程的时间点，并提供建议的工具或脚本来完成相应过程。

迁移依赖关系

Hyper-V 角色不依赖于任何其他角色。 作为最佳实践，建议不要在运行 Hyper-V 的服务器上安装任何其他角色。

不支持的迁移方案

不支持以下迁移方案：

虚拟机的已保存状态。

下列一种情况下的虚拟机配置：

为虚拟机配置的虚拟处理器的数目多于目标服务器上的逻辑处理器的数目时。

为虚拟机配置的内存大于目标服务器上的可用内存时。

将物理服务器合并到虚拟机，或者将多个 Hyper-V 实例合并到一个实例。

Hyper-V 迁移概述

Hyper-V 角色迁移涉及将虚拟机、虚拟网络和所有关联的设置从企业中的一台物理计算机移动到另一台物理计算机。 该过程支持从在 Windows Server® 2008 R2 中运行 Hyper-V 的服务器迁移到在 Windows Server 2012 中运行 Hyper-V 的服务器。 Hyper-V 角色不依赖于任何其他角色。

迁移工具包含你可用于执行迁移 Hyper-V 角色所需的某些任务的 cmdlet。 Export cmdlet 可捕获执行成功迁移所需的大多数 Hyper-V 设置，包括虚拟机配置、虚拟网络和虚拟硬盘。 DCOM 和 WMI 命名空间安全设置必须单独进行迁移。 本指南后面提供有关此操作的说明。 在目标服务器上，Import cmdlet 将重新创建虚拟机。

迁移的影响

下节描述迁移对源服务器和企业中的其他计算机的影响。

迁移对源服务器的影响

在目标服务器上运行 import cmdlets 之前，应当关闭源服务器或从网络中删除源服务器，以便在源服务器上运行的虚拟机与将在目标服务器上重新创建的虚拟机之间没有冲突。 本指南后面的迁移步骤中标识应执行此任务的时间点。

迁移对企业中的其他计算机的影响

这种迁移可能会影响依赖于在虚拟机（将作为 Hyper-V 角色迁移的一部分进行迁移）中运行的应用程序或工作负荷的任何计算机（虚拟或物理），因为这些虚拟机在迁移期间将处于脱机状态。 例如，如果虚拟机承载一个数据库，则企业中需要访问该数据库的所有应用程序都将受到影响。 因此，你将需要通过安排计划的中断时间或通过将流量重定向到其他服务器以提供相应服务，从而安排好此类停机事件。

完成迁移所需的访问权限

运行 cmdlet 和工具的用户帐户必须是源服务器和目标服务器上的本地管理员组的成员。

估计持续时间

迁移 Hyper-V 角色所需的时间长度取决于要传输的数据大小。 在要传输的各种文件类型当中，vhd 文件的文件大小最大（从几千兆字节到数千兆字节不等）。 时间长度受到 vhd 文件的大小和网络带宽的影响。

网站的空间有独立与虚拟之分，下面分别介绍两种空间的搬家方法。

　　一、独立主机

　　网站搬家即数据的迁移，搬家前不论独立还是虚拟主机，网站都需关闭。数据的迁移分为数据库数据及程序和附件文件两部分的的迁移。

　　数据库的迁移：首先停止老服务器上的 MySQL。复制 MySQL 数据存放目录下的数据文件，至于MySQL 的数据存放目录，可以查看 MySQL 配置文件中的 datadir 参数。（对于 Linux 系统的 MySQL配置文件一般为 /etc/mycnf ，Windows 环境下为 MySQL 安装目录路径的根目录下的 myini 文件。）

将数据文件移到新服务器相对应的 MySQL 数据存放目录下，这里注意到的一点就是对于 Linux 系统，注意移动数据文件之后，将相对应的文件属主改成你的 MySQL 运行账号。

　　程序和附件的迁移：将你的老服务器 WEB 目录下所有文件移到新服务器的 WEB 目录即可。

　　修改配置文件信息：

1、Discuz! X15 的配置文件在 config 目录下，即 configglobalphp 和configucenterphp 两个文件。

2、UCenter 的配置文件在 data 目录下，即 configincphp 文件。

配置文件里记录的数据库地址、访问用户名、密码都要根据你的新服务器的相应信息进行修改。同时，如果你的域名发生变化，要修改配置文件中相应的域名信息。

3、由于 UCenter 的后台存放了各个应用的配置信息，所以当你修改完配置文件的信息之后，对应的需要去 UCenter 的应用管理中，把对应的信息（尤其是 IP 和域名）校正为正确的地址。

　　至此，对于独立主机用户的站点快速搬家流程说明完毕。整个流程比较简单，唯一消耗的主要在于时间，当然这需要根据你的站点和传输速度而定。

二、虚拟主机

　　虚拟主机的数据库数据一般站长是直接拿不到的，最好是通过网站后台备份数据库数据，然后到新的空间中恢复数据库的备份就可以了，但新空间要全新安装一遍程序。

1、备份：

　　网站的数据部分，可以在 UCenter 后台直接进行备份，

登录 UCenter 后台→数据备份

在 UCenter 下可以只备份 UCenter 的数据，也可以备份所有应用或者部分应用的数据，这里我们选择备份所有应用的数据。提交后等待备份完成，可以到数据备份记录里查看。这里需要注意的是，在 UCenter 备份的整站数据有两部分，分别存放在 UCenter 和 Discuz! X 里面各一部分：UCenter 是在/uc_server/data/backup_日期_ABCDEf（ABCDEF是备份数据名称范例）；Discuz! X 是在网站根目录 /data/backup_日期_ABCDEf（ABCDEF是备份数据名称范例）。很多人的问题就出现在这里，上传数据库备份文件的时候，千万要注意这两个备份文件要放到正确的位置，避免数据不完整丢失，造成会员，帖子等数据出错。

　　备份程序文件相对于虚拟主机来说，就要特别注意 UCenter 和 Discuz! X 的配置文件和存在 UCenter 中的头像等的备份。

　　备份 UCenter 的所有程序文件，其中要注意 data 目录以及其下的 configincphp 文件一定不能丢失，data 目录下的 backup 目录下存放的是刚才备份的数据，avatar 目录下存放的是所有会员的头像，所以这些文件一定不能丢失。

　　备份论坛的所有程序文件，其中要注意 data/attachment 附件目录以及 config 目录下的 configglobalphp和configucenterphp 文件一定不能丢失。如果有模板风格的，也要单独备份后下载，待新空间安装完毕，再重新上传启用；之前网站有通过DIY的页面，这时要导出备份，新空间装完再导入即可。

　　还有一点很重要：确保搬入服务器和原服务器的数据库版本和编码一致，如果编码一不致可能会出现乱码的情况。

2、安装新程序及附件、头像等的上传

　　全新安装论坛，安装的时候 Discuz! X 及 UCenter 数据库名以及表名前缀一定要和原来的一致；

程序头、尾（如果有改动）、diy数据都要重新覆盖；下载到本地的附件、头像等数据上传到新空间正确的位置；伪静态规则文件、模板文件及Logo网站标识等重新上传到新空间正确位置。

3、恢复数据库

　　首先登录到 UCenter 后台，检查各应用是否通信成功，然后用创始人登录：

UCenter 后台→数据备份→数据备份记录→数据恢复→（找到相应的备份，如果备份显示不存在，那就说明备份文件上传的位置错了！）点击“详情”→选择备份的数据→提交。

4、后续操作

　　由于 UCenter 以及 Discuz! X 的 URL 路径和之前比发生了变化，所以要在 UCenter 后台修改为正确的路径。

UCenter 管理后台→应用管理→编辑

Discuz! X 的 URL 路径。检查应用的 UCenter 配置信息，UCenter 管理后台→应用管理→编辑论坛的应用，找到应用的UCenter 配置信息，复制其中的全部内容，分别覆盖到论坛的 config 文件最后的关于 UCenter 的配置信息部分。更新UCenter及论坛的缓存后，网站搬家基本就好了，剩下的伪静态等问题，要确认服务器设置好 rewrite 后，在设置开启。

itjobjava老师教过客户由于以下原因可能会要进行OA的迁移

1) 项目实施阶段，通过某项测试，把通过测试的机器的OA环境搬迁到另一台机上

2) OA应用服务器硬件升级或故障，为了不影响OA正常使用，需要搬迁

3) OA应用做双机互备，双机热备等

此OA应用服务迁移如果涉及OA数据库的变动，请参考『迁移OA数据库』。

1 相同操作系统间迁移，如从一台windows2003系统机器迁移到另一台windows2003系统机器

直接把$OA_HOME目录拷贝到另一台机器相同路径下（如果拷贝到另一台机器的路径不相同，方法请参考跨操作系统迁移，来修改路径参数）；

2跨操作系统迁移（如从windows操作系统迁移到linux）或者在同一台机器下不同路径下迁移

将$OA_HOME目录压缩成tar格式，然后上传到目录机器上，解压到需要的路径下

请检查以下这些文件，将路径修改成实际的路径：

1．$OA_HOME/TomcatX/conf/serverxml文件Context path="/oa" docBase=" E:/OA/firstframe/webapp"中docBase的值

或者$OA_HOME/ApusicX/config/serverxml文件application name="oa" base =" E:/OA/firstframe/webapp "中base的值

2．$OA_HOME/firstframe/bin/set-server-envbat(非windows环境：$OA_HOME/firstframe/bin/initsh)文件中OA_HOME，JAVA_HOME，JRE_HOME等参数的路径值

3．$OA_HOME/firstframe/resources/firstframeproperties文件中constantmain_storage_dir的值（OA公文处理表单等文件的存放目录路径）

Windows cluster要求同一个cluster中的所有windows版本都是相同的，这样就出现一个问题，当我们要将对windows进行升级时，(例如从windows 2008 R2升级到windows 2012)不得不搭建一套新的windows cluster。你可以选择使用新的硬件搭建，或者将现有windows cluster中的节点一台一台的evict掉，重装/升级系统后加入到新的windows cluster中。具体的cluster升级方案我就不在这里讨论。马上进入主题：

sql server AlwaysOn Availability Group (后文简称为AG) 的一个要求是：所有的replica都要求隶属于同一个windows cluster。

   所以当我们对windows cluster进行升级时，无法在新的windows cluster和现有的windows cluster之间建立AG。那么在迁移过程中会有一段时间内AG无法对外提供服务。

从数据库的角度上说，我们需要做下面的事情

接下来停止应用并删除cluster1中的Listener，确保没有外界来接使用SQL SERVER

Backup database

Backup tail log

将备份文件copy到新的服务器

Restore 到各个服务器

然后重新建立AG

创建Listener

重启应用

我们需要将数据库备份并还原到新的primary replica和secondary replica。 相应的downtime时间就是1+2+3+4+5+6+7+8想要的时间。 或许你想到了在新旧cluster之间创建一个mirroring，但遗憾的是，创建了AG的数据库是不再允许创建mirroring的

那应当如何进行迁移呢从SQL Server 2012 SP1 开始，允许在两套不同的windows cluster之间创建AG。下面用一个例子说明一下

有一个三个节点的windows cluster, windows版本为Windows 2008 R2

Domain:liweiyin3lab

Cluster name: cluster1

Server002

Server003

Server004

Listener name: Listener1

三个节点上装有SQL Server 2012 SP1的standalone实例。均为默认实例。

之间建立了AG拓扑图如下：

   现在创建一套两个节点的windows 2012的windows cluster

Domain:liweiyin3lab

Cluster name: cluster2

Server005

Server006

   对cluster1上的AG数据库进行备份，包含full database backup和log backup两个cluster中间创建AG：

将第一步得到的文件在cluster2的节点上进行还原，指定为with norecovery

接下来在cluster2的三个数据库上执行下面的语句

ALTER SERVER CONFIGURATION SET HADR CLUSTER CONTEXT='cluster1liweiyin3lab'

这条语句执行完毕后，这台数据库的cluster context就会切换为cluster1了。这个结果可以从下面的DMV中检查到

select cluster_name from sysdm_hadr_cluster

   接下就可以在cluster1和cluster2之间建立AG。我们可以使用UI或者T-SQL语句。

需要注意的是，请将cluster2中的至少一个SQL Server的同步模式设置为Synchronous commit,以保证迁移是没有数据损失的。

   这样，我们就建立了一套既包含win 2008R2，也包含win 2012的AG环境了。并且也可以正常地向外界提供服务，整个流程不需要downtime

   但需要注意的是，这种情况下是不允许在两个cluster之间进行failover的。相应的提示信息如下

   An attempt to fail over or create an availability group failed This operation is not supported when AlwaysOn Availability Groups is running under a remote Windows Server Failover Clustering (WSFC) cluster context Under a remote cluster context, failing over or creating availability groups are not supported

   接下来停止应用并删除cluster1中的Listener，确保没有外界来接使用SQL SERVER

在Cluster1将AG进行offline操作

ALTER AVAILABILITY GROUP dbName offline

将cluster2中所有sql server的CLUSTER CONTEXT切换回来

ALTER SERVER CONFIGURATION SET HADR CLUSTER CONTEXT=local

在cluster2中重新创建AG

在cluster2中创建新的listener

重启应用

这样所涉及的downtime就是5+6+7+8+9+10

和之前的解决方案相比，省去了backup，文件copy和restore的时间。其余的操作都是句操作，很大程度地减少了downtime。

更多信息

===

迁移之前，Cluster2中的sql server不允许创建任何AG。

迁移之前需要授予cluster2中的sql server启动账号访问cluster1注册表的权限

Change the HADR Cluster Context of Server Instance (SQL Server)