ralish's Posts

Are there any plans to supported nested virtualisation under Windows Hypervisor Platform? If Hyper-V is installed, or any of several security features are enabled on the host OS (Virtualisation Based Security), then the Windows Hypervisor Platform is used instead of VMware's native hypervisor. This breaks support for VMs which required nested virtualisation (e.g. ESXi guests, Windows guests that themselves have VBS enabled). The underlying support appears to be present in the Windows Hypervisor Platform given nested virtualisation can be used on VMs directly created using Hyper-V, but VMware Workstation does not have any awareness of it. Previously discussed on these topics but have not received any comment from VMware: Nested hypervisor support under VBS (inc. Device Guard) Nested hypervisor support under VBS

Are any VMware developers monitoring this forum able to comment on future support for nested hypervisors on systems with Hyper-V (or dependent features like Device Guard)? At the time host VBS support was introduced back in Workstation v15.5.5 my understanding was this feature was missing due to limitations in the Windows Hypervisor Platform API. Is this still the case? Are there any plans to add support and what are the roadblocks to doing so? If at all helpful as background, my use case is testing VBS configurations in VMs on a host which itself uses VBS, as well as wanting to test ESXi configurations in a VM. Both of these scenarios require Intel VT-X/EPT virtualisation (or AMD-V/RVI for AMD CPUs), which isn't supported with host VBS. Thanks in advance!

Posting to document an issue I encountered while updating to VMware Workstation Pro v15.5.6 from v15.5.5 which was not trivial to track down. Now that VMware Workstation is compatible with Hyper-V and features which rely on it (e.g. Device Guard, Credential Guard, etc ...) it's possible to have those features installed side-by-side and use them in tandem. One of those features is Windows Defender Application Guard (WDAG). The WDAG container (a lightweight Hyper-V VM) maintains open handles to many driver catalog files located at C:\Windows\System32\CatRoot. This includes catalog files for VMware drivers which need to be updated during the upgrade process. The result is the upgrade process will fail with any of several possible messages. I personally witnessed errors referencing vsock (as a pop-up dialogue during upgrade), but after the upgrade failure and subsequent rollback, only saw generic failure messages without any pop-ups on subsequent attempts. In both cases the issue was due to driver catalog files being open by the WDAG container. The workaround is fortunately simple but not obvious. Simply stop the Application Guard Container Service (hvsics) before attempting the upgrade. This will stop the WDAG VM process maintaining the open file handles. Once the upgrade process is complete the service can be safely restarted. I'm not sure if the VMware Workstation Pro installer can better handle this case, but if not, it probably at least merits a reference as a Known Issue in the release notes to save others potentially a lot of trouble.

When copying files from the guest to the host with VMware Tools (not using SMB, FTP, etc ...) the mechanism is very inefficient. Consider the following scenario assuming a 10GB file to be copied from the guest to the host: VMware Workstation copies the file from the guest to a temporary location on the host system. Windows Explorer *copies* the file from the temporary location to the desired location on the host. Assuming the destination location is on the same volume as the temporary location twice as much storage space as should be needed is used. In addition, the temporary file is not removed, so the wasted storage space is retained indefinitely until a background process performs clean-up of temporary files. For large files, this process means the copy takes around twice as long as should be required given the redundant second step. I'd suggest the following changes: Where the destination location resides on the same volume as the temporary storage location a move should be performed resulting in no wasted space and a halving of time required. If the destination location resides on a different volume from the temporary storage location, the data should be removed from the temporary location after the copy is completed. Ideally the file should be directly copied to the destination location instead of using an intermediate temporary location but I expect there are additional factors here. The above suggested improvements should apply to the vast majority of copy operations while being relatively simple to implement? All testing performed on Windows 10 v1903 x64 w/ VMware Workstation v15.5.0. Thanks in advance.