Command: "enableSharedFolder", error: the virtual machine is not powered on

[OlafHaalstra]

Let me start off with saying that DetectionLab is really awesome work and loving it ever since I discovered it!

• Operating System Version: Windows 11 - 21H2 OS BUILD 22000.376
• Deploying via (VirtualBox/VMWare/AWS/Azure/ESXi): VMWare
• Vagrant Version (if applicable): Vagrant 2.2.19

Please verify that you are building from an updated Master branch before filing an issue. ✅

Description of the issue:

While bringing any box up (logger, dc, wef or win10) the following error is presented:

An error occurred while executing `vmrun`, a utility for controlling
VMware machines. The command and output are below:

Command: ["enableSharedFolders", "D:\\DetectionLab\\Vagrant\\.vagrant\\machines\\win10\\vmware_desktop\\d929dfab-247c-470f-9772-8300c26661d6\\windows_10.vmx", {:notify=>[:stdout, :stderr]}]

Stdout: Error: The virtual machine is not powered on: D:\DetectionLab\Vagrant\.vagrant\machines\win10\vmware_desktop\d929dfab-247c-470f-9772-8300c26661d6\windows_10.vmx

Stderr:

I can verify that the machine is in fact up and running:

> "C:\Program Files (x86)\VMware\VMware Workstation\vmrun.exe" -T ws list
Total running VMs: 4
D:\DetectionLab\Vagrant\.vagrant\machines\logger\vmware_desktop\4d1820ef-86a7-43e5-8da5-0e08f4478556\ubuntu-20.04-amd64.vmx
D:\DetectionLab\Vagrant\.vagrant\machines\dc\vmware_desktop\b2ca2ca9-c264-461f-8d9b-5342290ac81c\WindowsServer2016.vmx
D:\DetectionLab\Vagrant\.vagrant\machines\wef\vmware_desktop\c3b7afe4-cf0d-45f9-9d8f-c483642c96ef\WindowsServer2016.vmx
D:\DetectionLab\Vagrant\.vagrant\machines\win10\vmware_desktop\d929dfab-247c-470f-9772-8300c26661d6\windows_10.vmx

This also happened a few times when bringing up the machines after completely removing them. After a few runs of vagrant reload [host] --provision eventually it completed the sequence without this error. Some things are working: given that the logs are coming into Splunk with no problem (did not test all functionality).

However some things seem to be a bit flaky, e.g. pinging hosts from the DC (also can't reach the c$ share of win10.windomain.local, neither works via IP):

Any idea what might go wrong here? Everything destroying all VMs and or repeatedly reprovisioning them doesn't sound like the correct solution

[OlafHaalstra]

I see that the issue is already described before in: https://github.com/clong/DetectionLab/issues/289 and https://github.com/clong/DetectionLab/issues/447 and https://github.com/clong/DetectionLab/issues/720 (slightly different error, stating the VMWare Tools are not running).

The proposed earlier solution did not work:

This should be fixed with vmware_desktop Box v1.2 Destroy all existing VMs: vagrant destroy -f Update boxes: vagrant box update detectionlab/win10 && vagrant box update detectionlab/win2016 Remove old boxes (optional, but recommended): vagrant box prune

[OlafHaalstra]

What did work for me is as soon as the script has reached:

==> win10: Enabling and configuring shared folders...

You reinstall the VMware tools manually, after that it will pick up automatically and continue the provisioning.

[tuedenn]

I had the same error. And what i have done to solve this is:

1. when it raises a err like: "Command: ["enableSharedFolders", ....", log on to DC machine (VMWare in my case), and install VMtools manually (VM -> Install VMWare tools)

2. try vagrant reload dc --provision to reload DC machine, again!

3. Its worked! modern problems require modern solutions! :) I think UAC (when) is the main problems to cause this issue (correct me if im wrong)

[clong]

Hi folks, there's more context here (https://github.com/clong/DetectionLab/issues/720) but the long story short is there's a race condition when the hostname is getting set. When the VM boots for the first time, it also has to configure VMware tools to re-configure itself (due to sysprep having run). If VMware tools setup completes before the hostname change, everything will work fine. If not, you'll run into this issue. I still haven't found a solid fix for this yet.

[clong]

This might be solvable by disabling the Vagrant hostname setting and just using powershell to do it via Rename-Computer

[clong]

Closing as this is now being tracked in #720