##################################################
目录
虚拟机 Hyper-V 与 VMware 虚拟机和 VirtualBox 虚拟机不兼容
在服务中将 Hyper-V 服务停用以及设置成手动不能解决虚拟机冲突问题
##################################################
虚拟机 Hyper-V 与 VMware 虚拟机和 VirtualBox 虚拟机不兼容
——————————
莫名其妙的错误
今天想在 Linux 下测试一下 ADB
然后发现 VirtualBox 打不开了：
以管理员权限运行打开是倒是打开了
但是不能运行虚拟机：
这莫名其妙的报错？？？
不能为虚拟电脑 FreeBSD 13 打开一个新任务.
The native API dll was not found (C:\Windows\system32\WinHvPlatform.dll) (VERR_NEM_NOT_AVAILABLE).
VT-x is not available (VERR_VMX_NO_VMX).
返回 代码: E_FAIL (0x80004005)
组件: ConsoleWrap
界面: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}还以为是莫名其妙更新了导致扩展包不匹配 重新安装对应的扩展包之后仍然如此
无奈 只好转到 VMware 下
然后发现 VMware 也不能启动了！！！
好家伙 我终于意识到问题有多严重！！！
思来想去 越发觉得跟微软的 Hyper-V 虚拟机脱不了干系
——————————
Hyper-V 与其她的虚拟机不能共存
最后终于找到了原因
微软的 Hyper-V 虚拟机在启用的时候 宿主机也被虚拟化了！
以至于在宿主机上直接访问 CPU 的其她虚拟技术会失效！
即使 VT-X 在 BIOS 里面开了 Intel 的 CPU 检测工具也会报告 CPU 不支持 VT-X
可以在管理员命令行下运行 bcdedit /set hypervisorlaunchtype off 之后重启来关闭 Hyper-V
Hyper-V 是一个 type 1 hypervisor
当在 Windows 中启用 Hyper-V 时 Windows 系统在硬件底层与 Windows 应用层之间插入了一层薄薄的 Hyper-V
而原来的 Windows 系统应用层则变成了一个运行在 Hyper-V 上的虚拟机！
而 VMWare 和 VBox 虚拟机使用一种被称为虚拟机监视器 Virtual Machine Monitor/VMM 的机制
是直接访问 CPU 内建的虚拟化功能，因此，她们本身不能在虚拟机环境中运行
换句话说，不支持嵌套虚拟化 nested virtualization
当 Windows 启用 Hyper-V 时 原来的 Windows 变成了虚拟机环境
偏偏 VMWare Workstation 与 VirtualBox 不能在虚拟机环境中运行
因此，运行 VMWare Workstation 与 VirtualBox 时会报错甚至还有其她错误
安装 Visual Studio 以后可能会导致与 VirtualBox/VMware 产生冲突
这是因为安装了 Windows Phone SDK冲突表现为打开 VirtualBox、VMware 创建 64 位虚拟机时，出现了如下错误：
VT-x/AMD-V hardware acceleration has been enabled, but is not operational. Your 64-bit guest will fail to detect a 64-bit CPU and will not be able to boot.
Please ensure that you have enabled VT-x/AMD-V properly in the BIOS of your host computer.
这也是因为 Windows Phone SDK 在安装时打开了 Hyper-V 导致的
Windows Phone SDK 中的手机模拟器需要用 Hyper-V 来实现虚拟化
Hyper-V 是微软的虚拟化软件，类似 VirtualBox/VMware 可以用来创建虚拟机
她们被称为 Hypervisor 或 Virtual Machine Monitor/虚拟机监视器
由于 Hyper-V 与 VirtualBox/VMware不能共存
因此当 Hyper-V 打开时 VirtualBox/VMware 就不能正常工作了
上面错误提示中提到的 VT-x/AMD-V 是处理器的硬件虚拟化支持
已经在 BIOS 中打开了但是 Hyper-V 使用了她
于是 VirtualBox/VMware 就抱怨说 无法使用/not operational 了……——————————
在服务中将 Hyper-V 服务停用以及设置成手动不能解决虚拟机冲突问题
VMware 公司的 Workstation 肯定是很多人一直使用至今的
但毕竟这是属于寄居架构的虚拟化 而原生架构的才是企业虚拟化的不二选择
但微软的 Hyper-V 也逐渐展露头角
在我们学习的过渡期，我们通常会希望可以同时使用 VMware Workstation 和 Hyper-V
但似乎这两款应用充满了排斥，有时我们安装成功 可使用了 Hyper-V 服务之后，我们会发现 VMware Workstation 打不开了
在网上看到一个方法：
既然都可以安装，只是无法一起运行，那么我们可以通过关掉 Hyper-V 的服务
就能在系统上跑 VMware Workstation 了
于是亲自一试 cmd 命令中运行
services.msc以打开服务窗口：
找到 Hyper-V 服务
发现这些服务对应的服务名在任务管理器中也能关掉：
将以下服务设置成手动：
服务名 显示名 描述 文件路径
vmms Hyper-V 虚拟机管理 Hyper-V 的管理服务提供运行多个虚拟机的服务。 C:\Windows\system32\vmms.exe应用后确定
重新启动即可！
重启之后这些服务一个没开：
看到是关闭的：
仍然不行：
这证明当前系统还是运行在虚拟机上？！！！
以后启动 Hyper-V 虚拟机需要手动开启服务：
点击开始：
之后可以成功运行 Hyper-V
真是偷鸡不成蚀把米 还是把服务改回自动吧：
对应的关闭命令如下
使用管理员权限运行 CMD 输入以下命令：
bcdedit /set hypervisorlaunchtype off
对应打开 Hyper-V 如下：
bcdedit /set hypervisorlaunchtype auto
重启：
shutdown -r -t 0
——————————
最狠的解决办法 —— 卸载 Hyper-V
一山不容三只老虎！命令行 OptionalFeatures 进 启用或关闭 Windows 功能取消勾选 Hyper-V
怎么安装的就怎么卸载 完毕之后重启系统其她虚拟机就正常了！
——————————
最硬核的办法 —— 一个 Windows 系统变成两个用
%%%%%
把一个 Windows 系统变成两个系统使用
一个加载 Hyper-V 的驱动服务 而另个一个不加载
但实际上系统还是一个 只是在我们启动系统时会看到两个启动菜单
一个可以使用默认启动 Hyper-V 一个默认不启动 Hyper-V
%%%%%
Windows 启动带 Hyper-V
创建带 Hyper-V 虚拟机的 Windows 启动项：
bcdedit /copy {current} /d "Windows 10 AND Hyper-V"一定要记录下返回值：
此时指定这个启动项启动系统时自动启动 Hyper-V 虚拟机：
bcdedit /set {22f2bdca-a1a2-11ec-a045-e9cef8b60f00} hypervisorlaunchtype auto
如下：
Microsoft Windows [版本 6.3.9600]
(c) 2013 Microsoft Corporation。保留所有权利。
C:\Windows\system32>bcdedit /copy {current} /d "Windows 10 AND Hyper-V"
已将该项成功复制到 {22f2bdca-a1a2-11ec-a045-e9cef8b60f00}。
C:\Windows\system32>bcdedit /set {22f2bdca-a1a2-11ec-a045-e9cef8b60f00} hypervis
orlaunchtype auto
操作成功完成。
C:\Windows\system32>%%%%%
Windows 启动不带 Hyper-V
创建一个单纯启动 Windows 系统的启动项：
>bcdedit /copy {current} /d "Windows 10 NO Hyper-V"
已将该项成功复制到 {22f2bdcb-a1a2-11ec-a045-e9cef8b60f00}。
>返回值就是启动项编号 一定要记录下来
然后在这个启动项中加入命令 开机关闭 Hyper-V 虚拟机：
>bcdedit /set {22f2bdcb-a1a2-11ec-a045-e9cef8b60f00} hypervisorlaunchtype off
操作成功完成。
>
可以看到 WIndows 8.1 的启动编号为
22f2bdc?-a1a2-11ec-a045-e9cef8b60f00%%%%%
Windows r 调出运行窗口 打开系统配置：
msconfig
我的系统配置：
可以看到我们设置的启动项在这里了：
设置超时 10 秒
将 Windows 启动不带 Hyper-V 虚拟机设置为默认启动系统
点击应用点击确定：
点击确认重启：
%%%%%
之后重启系统选择不带 Hyper-V 虚拟机的启动项就能启动其她虚拟机啦！！！
虽然开机之后你看着还是在启动 vvms 服务：
虽然还是有报错问题：
但是虚拟机确实能用了：
启动 VMware 的话必须管理员权限了 不然会报错：
以管理员运行 VMware 虚拟机可以启动：
——————————
其她解决办法 —— 升级系统和软件 ！！！
不过从 VMWare Workstation/Player 15.5.5 版本开始 VMWare 公司重构了 VMM 机制
将 VMM 机制调整为在用户级别运行，不再直接访问硬件
而是通过利用微软的 Windows Hypervisor Platform /WHP 的 API 来运行
从而彻底解决了 VMWare Workstation/Player 与 Hyper-V 的冲突问题
如果你对如上的解决办法没有兴趣那么推荐你：
将 Windows 版本升级到 Windows 10 20H1 或更高版本
将 VMWare Workstation/Player 升级到 15.5.5 或更高版本只是安装时需要注意勾选 WMP ：
如果报错 VMware 在此主机上不支持嵌套虚拟化 模块 MonitorMode 启动失败 未能启动虚拟机
打开虚拟机的设置选项 找到 处理器 取消勾选虚拟化引擎里面的三个虚拟机选项后确定即可
##################################################
深入虚拟机架构
——————————
虚拟机分为两种架构类型
寄居架构 和 原生架构/裸金属架构 是虚拟机软件常采用的两种技术模式
其中裸金属模式虚拟机又分为微内核和单内核两种技术架构
与单内核架构相比 微内核具有更高的安全性
Hyper-V 采用的便是微内核架构
——————————
寄居架构
寄居架构主要是便宜 主要是自主学习使用 例如实验环境或测试环境
此架构下虚拟机作为应用软件安装在操作系统上 可以在此应用软件上安装多个操作系统
直接安装在硬件上的系统被称为宿主机
架构类型：
虚拟机_1 虚拟机_2
————————————————————
应用程序 应用程序 虚拟机监视器
————————————————————————————————————————
宿主机器
————————————————————————————————————————
硬件宿主机能上网则虚拟机就能上网
病毒木马都可以拖到虚拟机运行，与真机脱离，非常安全！
虚拟机监视器模拟出来的操作系统跟真实系统使用一模一样
真机怎么玩，虚拟机里也怎么玩
在虚拟机中模拟出来的生态系统跟真机一样，但是要注意：
虚拟机监视器也要占内存
所以电脑内存不够的话，虚拟机开的数量也有限制
但是真机一旦崩了，虚拟机当然也崩了……所以实际生产环境用的是原生架构
——————————
原生架构/裸金属架构
原生架构 费用昂贵 此时虚拟机按照 CPU 收费！
所以这是生产环境中使用 即企业中实际使用的服务器
此时虚拟机软件直接安装在计算机硬件上
虚拟机本身就是一个操作系统
在这个虚拟机中可以同时运行多个操作系统
原生架构：
应用程序 应用程序 应用程序
——————————————————————————————
原操作系统 虚拟机_1 虚拟机_2
——————————————————————————————
虚拟机监视器
——————————————————————————————
硬件——————————
Hypervisor 与 Typer 1/Typer 2
%%%%%
Hypervisor 是一种系统软件
她充当计算机硬件和虚拟机之间的中介
负责有效地分配和利用由各个虚拟机使用的硬件资源
这些虚拟机在物理主机上单独工作
因此 Hypervisor 也称为虚拟机管理器
%%%%%
Typer 1 Hypervisor
原生/裸机 Hypervisors
直接和硬件进行交互 她不需要任何操作系统
可以直接把她安装在硬件上面，让她作为一个被宿主机
Typer 1 Hypervisor 也被叫做 Bare Metal/Embedded/Native Hypervisor
更高的性能
降低资源使用率
固件位置更安全
运行虚拟化生产环境
需要主动管理
%%%%%
Type 2 Hypervisor
Type 2 Hypervisor 往往安装在某个系统之上
她也被叫做 Hosted Hypervisors
她的操作当然也要依靠她寄托的操作系统
Type 2 的主要优势就是她有更广泛的硬件支持
Type 2 主机执行软件虚拟化
她们在主机操作系统上作为软件应用程序运行
与基于硬件的 Type 1相比 她们更像是已经安装的应用程序
大多数 Type 2 用户利用这个更简单的 Hypervisors 在单台计算机上运行虚拟机
而不像 Type 1 的部署和管理那样复杂
设置更简单
易于管理
基于软件的虚拟化与各种硬件兼容
不需要专门的管理员
在 Windows/OS X/Linux 环境中测试多个系统
类型 1 可能仅仅支持一些驱动程序 但是类型 2 可以完全访问 Windows 或 Linux 驱动程序
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
