Virtual PC | Virtual Server | Hyper-V | App-V

Hyper-V_logo

使用Hyper-V VLAN功能组建受隔离的网络环境

        在开始今天的分享前,gOxiA 带着大家前先了解下面的截图,这样才能更好的理解所要分享的内容。在一个企业网络内(Corp LAN),已经部署了DC、DNS、DHCP、WDS等服务器,是一个完整的生产环境。在 10.1.50.x 的子网内 gOxiA 有三台 Hyper-V 主机(两台基于 Windows 10,一台基于 Windows Server 2016)进行工作相关的测试和评估。

Hyper-V_VLAN

        默认情况下三台 Hyper-V 主机与 Corp LAN 是可以相互访问的,这个应该很容易理解吧;现在为这三台Hyper-V 主机分别创建了虚拟交换机 vNet-LAN50,那意味着其上的虚拟机将从 10.1.50.x 获取网络地址,并运行相互访问,到这里也很容易理解吧;由于一些测试需要进行隔离,通常会在Hyper-V 主机上创建 VMs Only LAN,仅供当前Hyper-V 主机上的虚拟机相互访问,或在当前 vNet-LAN50 上启用 VLAN 分配 ID 20 进行隔离,到这里相信也能理解;OK,我们继续,现在由于一个测试任务过于庞大所需的硬件资源很高,无法在一台Hyper-V主机上进行,需要现有的三台 Hyper-V 主机组网使用,且不变动现有的物理网络环境,同时实现与现有逻辑网络隔离。

        如果为每台虚拟机创建单独的网络,如192.168.192.x,是可以实现相互通讯的,但是并未完全实现逻辑网络的隔离,假如虚机部署了 DHCP 服务,那么极有可能会对现有的 Corp LAN 产生影响。但是启用虚机 VLAN 后,怎么实现跨 Hyper-V 主机访问呢?!按理说 vNet-LAN50 这个虚拟交换机的物理接口是 Hyper-V 主机上与 10.1.50.x 相连的网卡,由于是透明通讯,虚拟机设置 VLAN20 后理应透过 vNet-LAN50 与其他 Hyper-V 主机上 VLAN20 的虚机通讯,但是现实很残酷并非如所想的那样!!!

        经过测试需要通过 Hyper-V 的 Virtual Switch Manager(虚拟交换机管理器)为当前网络即 vNet-LAN50 也启用 VLAN ID 20,才能实现跨 Hyper-V 主机 的 VLAN 段虚机互访。

image

        虽然该法实现了最终的需求,但也确实与现有逻辑网络完全隔离,这意味着原有 10.1.50.x 段中的其他设备将无法访问这三台 Hyper-V 主机,否则也必须修改 VLAN 为 20。(如果 Hyper-V 主机是多宿主,倒是很好解决!)

Windows_Server_2016_logo_banner

工作组环境下使用 Hyper-V 管理器远程管理 Hyper-V 主机

        参考本文将能协助你轻松地在工作组环境下通过Windows 10 的 Hyper-V 管理器去远程管理 Hyper-V 主机。在之前的系统版本上,我们需要依赖一系列的配置操作,或使用现成的脚本才能才能实现,否则就需要确保客户端和服务器都加入到域环境。

        在 Windows Server 2016 环境中,之前的配置方法和脚本都不再有效。还好微软分享了一组系统命令和简单的操作步骤,就能够实现我们的需求。

        首先,在 Windows 10 设备上通过“程序和功能”,启用 Hyper-V 管理器(Hyper-V Management Tools),由于 gOxiA 的客户端是英文版,所以具体如下图所示:

Hyper-V_Management_Tools

        然后,在 Hyper-V 主机上执行配置命令行,以便接收 Windows PowerShell 远程命令发送的 WS-Management 指令,同时还要为 WS-Management 配置允许 CredSSP 身份验证。为此,我们需要执行两条命令:

1、 Enable-PSRemoting

2、 Enable-WSManCredSSP -role server

        具体的执行效果可参考下图:

enable-psremoting

        至此,Hyper-V 主机端的配置就算结束了,是不是非常简单便捷!接下来开始配置 Windows 10 客户端,同样需要先使用命令行进行配置。

1、Set-Item WSMan:\localhost\Client\TrusteHosts -Value "Hyper-V Host FQDN"

2、Enable-WSManCredSSP -Role client -DelegateComputer "Hyper-V Host FQDN"

        具体操作效果如下图所示:

con_client

        现在,执行 gpedit.msc 启动组策略管理器,定位至 计算机配置-管理模板-系统-凭据分配,启用“允许分配新的凭据用于仅NTLM服务器身份验证”,同时将“wsman/Hyper-V Host FQDN” 添加到服务器列表中,如下图所示:

con_client_gpedit1

con_client_gpedit2

        至此,配置过程告一段落,无需重新启动客户端和服务器,直接打开 Windows 10 设备上的 Hyper-V 管理器,添加计算机,填写“Hyper-V Host FQDN”,即 Hyper-V 主机的完整计算机名称,根据需要填写用于认证账号和密码,便可以连接到远程 Hyper-V 主机上进行愉快的操控。

con_Hyper-v_mgr1

con_Hyper-v_mgr2

参考资料:https://technet.microsoft.com/en-us/windows-server-docs/compute/hyper-v/manage/remotely-manage-hyper-v-hosts?f=255&MSPPError=-2147217396

Hyper-V - 增强会话模式

[ 2013/11/13 13:33 | by gOxiA ]

ws2012r2-logo

Hyper-V —— 增强会话模式

        Windows 8.1/Server 2012 R2 中的 Hyper-V 提供了一个新的功能,即:增强会话模式(Enhanced Session Mode),这个功能使得 Hyper-V 虚拟机连接器能够基于 RDP 方式进行管理,或者说是 RDP 到虚拟机的连接基于 VMBus,gOxiA 个人更倾向前一种说法,因为更加容易理解。因为在增强会话模式下,实现了很多 RDP 的功能,例如现在我们可以直接通过 VMConnect 从虚拟机中复制或粘贴文件或数据内容,而且还能够将本地资源重定向到虚拟机中。具体可参考下图:

image

image

        要启用增强会话功能,很简单!只需要在“Hyper-V 设置”中启用“允许增强会话模式”功能即可。

image

        当我们通过 VMConnect 以增强模式操作虚拟机时,只需要在菜单栏的“查看”中选择“增强会话”即可。

EnhancedMode

        当然,如果希望以后连接器打开虚拟机时都以增强模式访问,那么只需要在“Hyper-V 设置”下的“增强会话模式可用时使用”选项中复选“使用增强会话模式”即可。

image

        在使用增强会话模式时需要注意以下几点:

  • 增强会话模式目前仅支持 Windows 8.1/Server 2012 R2 虚拟机。
  • 增强会话模式支持第一代和第二代虚拟机。
  • 增强会话模式无需为虚拟机配置网络。
  • 增强会话模式无需为虚拟机系统启用RDP。
  • 只有支持 RDP 的 SKUs 才支持增强会话模式,即 Windows 8.1  Home 版不支持增强模式。
  • 增强会话模式无需 RemoteFX。
  • 增强会话模式不支持 OOBE。

ws2012r2-logo

HOWTO: 在 Hyper-V 虚拟机上安装 Hyper-V 角色

        作为 ITPro 是否想在现有环境中操作体验一下微软新的虚拟化平台——Hyper-V?!特别是希望学习 Hyper-V 的操作和各项选项设置,甚至是进行实时迁移或群集等实验,但又苦于没有现成的硬件可供测试?!有些朋友可能尝试直接在一台 Hyper-V 虚拟机上通过服务器管理器来安装 Hyper-V 角色,但是结果是安装向导提示无法进行角色的安装。

hyperv_on_vms_in_hyperv_1_thumb

        其实用户可以执行一系列的 PowerShell 命令行来强制安装 Hyper-V 角色,具体步骤如下:

  1. Enable-WindowsOptionalFeature –Online –FeatureName Microsoft-Hyper-V –All –NoRestart
  2. Install-WindowsFeature RSAT-Hyper-V-Tools –IncludeAllSubFeature
  3. Install-WindowsFeature RSAT-Clustering –IncludeAllSubFeature
  4. Install-WindowsFeature Multipath-IO
  5. Restart-Computer

hyperv_on_vms_in_hyperv_2_thumb

        通过此法能够在虚拟机上安装 Hyper-V 角色,也能创建虚拟机,但是虚拟机是无法正常启动和运行的。

hyperv_on_vms_in_hyperv_3_thumb

        虽然不能运行虚拟机,但是 Hyper-V 的诸多特性和功能还是可用的,比如我们可以在此环境中进行无需共享存储的实时迁移实验,也可体验一下 Hyper-V 的复制功能,甚至可将该虚拟机作为 Hyper-V 群集节点,进行 Hyper-V 故障转移群集的实验。

        注:该方法不受微软支持!!!

        参考:http://blogs.technet.com/b/gbanin/archive/2013/06/26/how-to-install-hyper-v-on-a-virtual-machine-in-hyper-v.aspx

ws2012r2-logo

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_Replication

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

image

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

image

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

1

选择虚拟机,启用复制。

2

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

3

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

4

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

5

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

6

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

7

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

8

9

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

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

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

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

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

ws2012r2-logo

在 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 管理器上的提示窗体截图没能保存下来,还好日志中有该问题的记录,提供出来给大家作为参考。

Hyper-V-VMMS_22042

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

image

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

image

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

logo_winserver2012

Windows Server 2012 使用 SMB 共享存储的实时迁移

live_migration_with_smb_shared_storage

        前几天 gOxiA 与大家分享了“Windows Server 2012 无需共享存储的实时迁移”,当我们了解了无需共享存储的实时迁移之后,对于 Windows Server 2012 使用 SMB 共享存储的实时迁移学习和实践起来就更加容易了!还记得之前的迁移过程中有一个步骤是让我们选择要移动的虚拟机项目吗?!其中“仅移动虚拟机”这个选项就是基于共享存储的实时迁移。

5

        既然是使用共享存储的实时迁移,那么文件共享是必须具备的前提条件,需要注意的是虽然是文件共享,但是我们必须使用基于 SMB 3.0 协议的文件共享服务器,大家可参考上一篇日志“Windows Server 2012 Hyper-V over SMB”进行准备工作。

        测试环境大致说明,两台 Hyper-V 主机已经加入到活动目录(AD),并在名为 Hyper-V 的主机上启用了 SMB 共享,为了确保使用 SMB 共享存储的实时迁移正常工作,我们需要做 Kerberos 委派,与“Windows Server 2012 无需共享存储的实时迁移”中提到的委派设置相同,添加 CIFS 委派即可,否则就会 出现如下图一样的错误。

12

        由于 SMB 共享是建立在一台 Hyper-V 主机上的,所以我们需要特别设置一下共享权限,将目录权限和共享权限都添加 everyone 有完全控制权限,否则在迁移时会出现错误,如下图所示。

13

        因为本机在访问位于本机共享资源的UNC时,会使用 user 权限进行验证,如果按照“Windows Server 2012 Hyper-V over SMB”中推荐的安全规范进行设置,会导致主机访问共享失败。

        一切准备就绪后,就可以开始迁移了,在 Hyper-V 移动向导过程中选择“仅移动虚拟机”,过程就是这么简单!对于此类的实时迁移,因为虚机的磁盘文件(VHD)始终位于基于 SMB 3.0 的文件服务器上,虚机的迁移只是将运行状态从一台主机迁移到另一台主机,当然 SMB 存储的链接也会被迁移过去,但是 VHD是绝不会被移动的。

5

logo_winserver2012

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 文件服务器。常见的部署方式有三种:

hyper-v_over_smb

        主要区别就是 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 并安装了文件共享服务。

image

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

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

1

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

2

3

4

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

5

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

6

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

7

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

8

9

10

        总结, 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

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 提供的方法来解决。

分页: 1/10 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]