VMware Workstation和Device/Credential Guard不兼容 [英] VMware Workstation and Device/Credential Guard are not compatible

问题描述

我去年一直在运行VMware没问题，今天我打开它来启动我的一个VM并收到错误消息，请参见屏幕截图.

我确实遵循了链接并完成了步骤，在步骤4中，我需要使用"mountvol"安装卷. 当我尝试使用mountvol X: \\?\Volume{5593b5bd-0000-0000-0000-c0f373000000}\挂载卷时，它总是说The directory is not empty.我什至创建了一个2GB的分区，并且仍然显示相同的消息.

我的问题:

如何安装不为空的卷(即使已为空)?

为什么此设备/凭据保护自动启用自身，如何摆脱或禁用它?

CMD:

解决方案

并且Hyper-V和VMware 不能同时工作，直到现在是VMware Workstation的预览版20H1 支持与Hyper-V并行运行:

随着2020 Tech Preview分支的第一个发行版20H1 Hyper-V时，用户现在可以在Windows 10上运行虚拟机 或主机基于虚拟化的安全性已打开.您可以运行设备 与VMware同时提供Guard，Credential Guard服务 工作站.

这需要Windows 10 20H1 2004 Build 19041和至少Intel Haswell或AMD Bulldozer CPU.

在此版本发布稳定之前，您必须将VM迁移到Hyper-V或禁用该功能.

如果要使用VMware，请在控制面板"->程序和工具"中取消选择"Hyper-V和隔离的用户模式/沙盒/Device Guard功能".功能->开启或关闭功能并重新启动设备:

I have been running VMware for the last year no problems, today I opened it up to start one of my VM and get an error message, see screen shot.

I did follow the link and went through the steps, on step 4 I need to mount a volume using "mountvol". when I try to mount a volume using mountvol X: \\?\Volume{5593b5bd-0000-0000-0000-c0f373000000}\ it keeps saying The directory is not empty. I even created a partition with 2GB and still the same message.

My Questions:

How can I mount the volume that is not empty even though it is?

Why did this Device/Credential Guard auto enable itself and how can I get rid of it or disable it.

CMD:

解决方案

Device/Credential Guard is a Hyper-V based Virtual Machine/Virtual Secure Mode that hosts a secure kernel to make Windows 10 much more secure.

...the VSM instance is segregated from the normal operating system functions and is protected by attempts to read information in that mode. The protections are hardware assisted, since the hypervisor is requesting the hardware treat those memory pages differently. This is the same way to two virtual machines on the same host cannot interact with each other; their memory is independent and hardware regulated to ensure each VM can only access it’s own data.

From here, we now have a protected mode where we can run security sensitive operations. At the time of writing, we support three capabilities that can reside here: the Local Security Authority (LSA), and Code Integrity control functions in the form of Kernel Mode Code Integrity (KMCI) and the hypervisor code integrity control itself, which is called Hypervisor Code Integrity (HVCI).

When these capabilities are handled by Trustlets in VSM, the Host OS simply communicates with them through standard channels and capabilities inside of the OS. While this Trustlet-specific communication is allowed, having malicious code or users in the Host OS attempt to read or manipulate the data in VSM will be significantly harder than on a system without this configured, providing the security benefit.

Running LSA in VSM, causes the LSA process itself (LSASS) to remain in the Host OS, and a special, additional instance of LSA (called LSAIso – which stands for LSA Isolated) is created. This is to allow all of the standard calls to LSA to still succeed, offering excellent legacy and backwards compatibility, even for services or capabilities that require direct communication with LSA. In this respect, you can think of the remaining LSA instance in the Host OS as a ‘proxy’ or ‘stub’ instance that simply communicates with the isolated version in prescribed ways.

And Hyper-V and VMware can't work the same time until 2020, when VMware uses Hyper-V Platform to co-exist with Hyper-V.

In Windows 10 we have introduced many security features that utilize the Windows Hypervisor. Credential Guard, Windows Defender Application Guard, and Virtualization Based Security all utilize the Windows Hypervisor. At the same time, new Developer features like Windows Server Containers and the WSL 2 both utilize the Windows Hypervisor.

This has made it challenging for our customers who need to use VMware Workstation. Historically, it has not be possible to run VMware Workstation when Hyper-V was enabled.

In the future – users will be able to run all of these applications together. This means that users of VMware workstation will be able to take advantage of all the security enhancements and developer features that are available in Windows 10.

There is now a preview of VMware Workstation 20H1 which supports running side by side to Hyper-V:

With the first release of our 2020 Tech Preview branch, version 20H1 users are now able to run virtual machines on Windows 10 when Hyper-V or host Virtualization Based Security is turned on. You can run Device Guard, Credential Guard services at the same time as VMware Workstation.

This requires Windows 10 20H1 2004 Build 19041 and at least Intel Haswell or AMD Bulldozer CPU.

Until this version is released as stable you have to migrate your VMs to Hyper-V or disable the feature.

If you want to stay at VMware, unselect the Hyper-V and Isolated user mode/Sandbox/Device Guard features in Control Panel->Program & Features->turn features on or off and reboot the device:

这篇关于VMware Workstation和Device/Credential Guard不兼容的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！