Unable to start minikube for hyperv if vmware module is present

[sanderma]

**this is a BUG REPORT:

Please provide the following details:

Environment:

Minikube version (use minikube version): v0.23.0

• OS (e.g. from /etc/os-release): Windows 10 Version 10.0.15063 Build 15063
• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): hyperv
• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION): minikube-v0.23.6.iso
• Install tools:
• Others:
  The above can be generated in one go with the following commands (can be copied and pasted directly into your terminal):

minikube version
echo "";
echo "OS:";
cat /etc/os-release
echo "";
echo "VM driver": 
grep DriverName ~/.minikube/machines/minikube/config.json

echo "";
echo "ISO version";
grep -i ISO ~/.minikube/machines/minikube/config.json

What happened:
If i try to start minikube with hyperv driver it tells me hyperv is not present when checking for the new-vm command

What you expected to happen: It should detect new-vm of the hyper-v module as hyper-v\new-vm works

How to reproduce it (as minimally and precisely as possible):

1. install the vmware module (VMware.PowerCLI)
2. make sure the hyper-v components are present.
3. check if the new-vm commands is present (get-command hyper-v\new-vm) -> note I am calling hyper-v\new-vm, otherwise it could be that the VMware.VimAutomation.Core\new-vm command is returned.
4. Start minikube with the hyperv driver

Output of minikube logs (if applicable):

Anything else do we need to know:
This is easily fixed, by checking if the hyper-v\new-vm command is present. It now checks for new-vm, Gets the first item of the returned array (in this case hyperv, and vmware), then checks the module it belongs to. If this is vmware, it fails.

Replace the new-vm powershell command with hyper-v\new-vm and check the entire array for hyper-v module to be present and this works as exepected.

[sanderma]

This is found in hyper-v\powershell.go on line 58. If that would to be stdout, err := cmdOut("@(Get-Command hyper-v\Get-VM).ModuleName") it would work as expected.
All the following new-vm lines should be hyper-v\new-vm though!

[Lacoste]

I wonder if I am seeing the same issue: I have the VMware PowerCLI modules installed as well, I received the following precreate check error during installation:

I1215 21:38:17.224997 10132 downloader.go:56] Not caching ISO, using https://storage.googleapis.com/minikube/iso/minikube-v0.23.6.iso
E1215 21:38:20.569346 10132 start.go:150] Error starting host: Error creating host: Error executing step: Running precreate checks.
: Hyper-V PowerShell Module is not available.
Retrying.
E1215 21:38:20.578158 10132 start.go:156] Error starting host: Error creating host: Error executing step: Running precreate checks.
: Hyper-V PowerShell Module is not available

I have tried running:
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Management-PowerShell
just to confirm that the PowerShell module is available, but this does not help.

The first time I run 'get-command new-vm', it lists it from the VMware module:
PS C:\> get-command new-vm
CommandType Name Version Source
----------- ---- ------- ------
Cmdlet New-VM 6.5.2.6... VMware.VimAutomation.Core

but if I specify hyper-v\new-vm it will list it, and then subsequent queries return hyper-v:
PS C:\> get-command hyper-v\new-vm
CommandType Name Version Source
----------- ---- ------- ------
Cmdlet New-VM 2.0.0.0 hyper-v

PS C:\> get-command new-vm

CommandType Name Version Source
----------- ---- ------- ------
Cmdlet New-VM 2.0.0.0 hyper-v

I tried removing the VMware module for the session, and still receive the error above.
PS C:\> Remove-Module VMware.VimAutomation.Core
PS C:\> get-command new-vm
CommandType Name Version Source
----------- ---- ------- ------
Cmdlet New-VM 2.0.0.0 hyper-v

[davemay99]

As mentioned above, the problem occurs because of a naming collision between commands in the Hyper-V and VMware PowerCLI modules. The affected code is in the docker machine driver, so I submitted a pull request to fix docker/machine#4404.

Not sure of the protocol here. Do I need to wait for Docker to merge my pull request, then submit a minikube pull request that incorporates all docker machine updates to that point, or should I submit a pull request that only fixes this specific issue?

[dlorenc]

Fixed by #2586