Hyper-V 外部虚拟交换机一建好，宿主机就断网——以及一次写进文档的"放弃"
想在两台在役的 Windows Server 2016 上启用 Hyper-V 角色，跑几台实验性质的虚拟机。两台服务器，两种死法，值得分开讲。
第一台：角色装好了，交换机建不得
这台是承载 ERP 应用的生产服务器。Hyper-V 角色本身安装顺利，问题出在下一步——创建外部虚拟交换机（External Virtual Switch）的瞬间，宿主机的网络整个断了：以太网连接显示已禁用/异常，服务器彻底失联。
这里有一个 Hyper-V 的基本机制值得展开：创建外部虚拟交换机时，Hyper-V 会接管物理网卡——物理网卡上原有的 IP 协议栈绑定被剥离，转移到一块新建的 vEthernet 虚拟网卡上，物理口降级为虚拟交换机的上联口。正常情况下这个”移花接木”会在短暂闪断后自动完成；但在某些网卡驱动/组合上，vEthernet 起不来或绑定迁移不完整，宿主机网络就再也回不来了——社区里这类案例一搜一大把。
当时的处置：进 Hyper-V 的 Virtual Switch Manager，把刚建的虚拟交换机删掉，物理网卡的绑定随之还原，宿主机网络恢复。之后在 Ethernet / vEthernet 适配器设置之间又试了几轮，结果都一样：交换机一建，网络就断。
最后在文档里写下的原话是：
GIVE UP. Insufficient time resources. Inconvenient environment to troubleshoot and play around.
这是一台跑着 ERP 的生产服务器，而且只能远程操作——每一次”再试一轮”都意味着一次生产系统失联的风险，而收益只是几台实验虚机。停手是对的。
在只能远程访问的生产服务器上，这个”短暂闪断”每次都是一场赌博
第二台：角色根本装不上，0x8007370
另一台服务器（RDS 用途）更干脆：Hyper-V 角色安装直接失败，错误码 0x8007370，“找不到引用的程序集（The referenced assembly could not be found）“。这个报错不是 Hyper-V 专属——装 Multipath IO、甚至装个 Telnet 客户端都可能撞上，指向的是组件存储（Component Store）层面的损坏或不一致。
社区的经验总结基本一致：这类问题常和区域/语言设置的不匹配有关（控制面板区域设置与系统组件包的语言标记对不上），有人指向注册表里 Component Based Servicing\PackageDetect 键值的手工清理——但同样是社区共识：注册表偏方大概率无效，绝大多数人最后都靠就地升级（in-place upgrade）解决。
微软支持给这台服务器的答复也是同一个方向：
你已经做得够多了。当前情况下最简单的方法是修复升级——从微软官网下载官方 ISO 镜像，运行安装程序做就地升级，升级后缺失的文件会被恢复，数据不会丢失。
就地升级相当于把操作系统的组件存储整个重建一遍，程序需要重装、数据保留。在排期做这个大动作之前，这台服务器上其他角色（如 WSUS）的安装不受影响——损坏是局部的，但要根治只有重建一条路。
教训
- 外部虚拟交换机 = 接管物理网卡——建它之前要预期一次网络闪断，并且在部分网卡驱动组合上有”断了回不来”的真实风险。在只能远程访问的机器上做这件事之前，先确认有带外管理（iLO/iDRAC）或现场支援兜底；
- 生产服务器不是实验环境——“顺手在 ERP 主机上开个 Hyper-V 跑实验虚机”这个想法本身就该被拦下来，实验负载去找专用宿主机；
- 把”放弃”如实写进文档是有价值的——GIVE UP 三个词加上原因（时间资源不足、环境不允许折腾），让几年后翻到这篇记录的人（包括自己）不用再把同样的坑踩一遍；
- 0x8007370 这类组件存储损坏，社区偏方成功率很低——微软支持自己都直接推荐就地修复升级，与其在注册表里考古，不如尽早排期走正路。