Hyper-V PowerShell Module is not available error when module is installed

[dariusj18]

Environment:

Minikube version (use minikube version): v0.25.1

• OS (e.g. from /etc/os-release): Windows 10 Pro
• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): n/a
• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION): n/a
• Install tools: Installed via isntaller and choco (same result)

What happened:

PS C:\WINDOWS\system32> minikube start --vm-driver hyperv --hyperv-virtual-switch "Primary Virtual Switch"
Starting local Kubernetes v1.9.4 cluster...
Starting VM...
E0322 15:54:09.998217 13800 start.go:159] Error starting host: Error creating host: Error executing step: Running precreate checks.
: Hyper-V PowerShell Module is not available.

Retrying.
E0322 15:54:10.002181 13800 start.go:165] Error starting host: Error creating host: Error executing step: Running precreate checks.
: Hyper-V PowerShell Module is not available
PS C:\WINDOWS\system32>

How to reproduce it (as minimally and precisely as possible):
Run minikube start --vm-driver hyperv --hyperv-virtual-switch "Primary Virtual Switch"

Anything else do we need to know:

It looks like line

minikube/vendor/github.com/docker/machine/drivers/hyperv/powershell.go

Line 64 in a000c35

if resp[0] != "Hyper-V" {

expects "Hyper-V", however when I run @(Get-Command hyper-v\Get-VM).ModuleName i get hyper-v (lowercase)

[dariusj18]

It looks like the version 1.1 of the Module reports as Hyper-V whereas the 2.0.0.0 reports as hyper-v

[jordansissel]

I am getting this error also.

> minikube --hyperv-virtual-switch=External --vm-driver hyperv start
Starting local Kubernetes v1.9.4 cluster...
Starting VM...
E0322 15:35:50.113731   14884 start.go:159] Error starting host: Error creating host: Error executing step: Running precreate checks.
: Hyper-V PowerShell Module is not available.

 Retrying.
E0322 15:35:50.118733   14884 start.go:165] Error starting host:  Error creating host: Error executing step: Running precreate checks.
: Hyper-V PowerShell Module is not available

For an odd data point, the module name is "Hyper-V" for me when I check directly, but minikube sees it the same as @dariusj18?

> minikube.exe version
minikube version: v0.25.1

> @(get-command get-vm).ModuleName
Hyper-V

> @(get-command hyper-v\get-vm).ModuleName
Hyper-V

Running minikube verbose:

> minikube --hyperv-virtual-switch=External --vm-driver hyperv --v 7 start
Starting local Kubernetes v1.9.4 cluster...
Starting VM...
[executing ==>] : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive @(Get-Command hyper-v\Get-VM).ModuleName
[stdout =====>] : hyper-v
...

Powershell -NoProfile, it's hyper-v lowercase?

> powershell -noprofile
> get-command hyper-v\get-vm

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

Powershell interactive/default, it's Hyper-V ?

PS C:\Users\jls> get-command hyper-v\get-vm

CommandType     Name                                               Version    Source
-----------     ----                                               -------    ------
Cmdlet          Get-VM                                             2.0.0.0    Hyper-V

I confess to not know what exactly is causing this. It's very strange, and I'm not convinced minikube is the problem, but maybe just a case-insensitive check will fix this?

[saitho]

#2639

[govind22]

I'm also getting this error.

I'm running win 10 with latest updates

[gbraad]

This should have been fixed with syncing: https://github.com/docker/machine/blob/1e3b6b64504f2970252b06119d6dc1fb1982b4b4/drivers/hyperv/hyperv.go

[gbraad]

For docker-machine, you need to have https://github.com/docker/machine/tree/1e3b6b64504f2970252b06119d6dc1fb1982b4b4/drivers/hyperv compiled as binary... however at the moment they haven't tagged and/or released this: Related issues: docker/machine#4424, docker/machine#4441

…

On Tue, Apr 3, 2018 at 2:20 AM, Gerard Braad ***@***.***> wrote: This should have been fixed with syncing: https://github.com/kubernetes/minikube/tree/125eede1530caca69ce442f58b9ce703434f5388/vendor/github.com/docker/machine/drivers/hyperv Make sure you run v0.25.2 => https://github.com/kubernetes/minikube/releases/tag/v0.25.2

-- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ]

[F21]

I am seeing this after upgrading to Minikube 0.26.0 on Windows 10 64-bit.

[andrewsav-bt]

@dariusj18 Not really, there is something else going on:

[gbraad]

They merged #2586, but this is a problematic PR... They should take #2634 (comment) as it uses the correct casing (this does affect, as we saw the same in Minishift) @dlorenc Please take: https://github.com/docker/machine/blob/1e3b6b64504f2970252b06119d6dc1fb1982b4b4/drivers/hyperv/hyperv.go ! /cc: @r2d4 @aaron-prindle

[AndrewSav]

@gbraad it does not appear that there is a "correct casing", rather that should be case insensitive. Also what is interesting, I don't have this problem with 0.25.2 only with 0.26.0.

[gbraad]

Well, we have experienced the same problem on Minishift's end. This fix was only taken for the latest point-release, so you are right to say you didn't have this with 0.25.2. If you actually look carefully at https://github.com/kubernetes/minikube/commits/v0.25.2 you can see @r2d4 took the fix I suggested => d564056 with the correct case. However, for some reason this fix is not in the master branch (and therefore also not in the 0.26.0 tagged release). The PR I pushed also changes the test to:

PS> @(Get-Module -ListAvailable hyper-v).Name | Get-Unique

which returns:

Hyper-V

Related issues: docker/machine#4426, docker/machine#4424, docker/machine#4441, and a ton of others on the Docker/machine end.

Minikube original synced docker/machine version 0.14.0 as tag, but these fixes only came AFTER the release was made. they are included in the Docker edge releases, but as of now, it is still untagged.

[AndrewSav]

@gbraad I'd like to repeat myself that there is no "correct case" this powershell module names are case insensitive. I have two machines with the same version of Windows, and Powershell and the case returned for the module is different (see here) unless you know explanation for that, the comparison should be case insensitive, as some other links I saw (sorry do not have them now) suggest that the module names in powershell are case insensitive.

I don't care as long as it works, I'm just pointing out, that stating that there is a "correct" case is dangerous, since empirical testing shows it's wrong.

[surajsubs]

With 0.26.0, I was having the same issue reported here. I noticed that the case of module name changes, between powershell and powershell in administrative mode. See screenshots below

Powershell Administrative mode

Regular Powershell

Downgrading to 0.25.2 did resolve the issue.

[gbraad]

@AndrewSav from your argument on StackOverflow, you also notice that the actual module names are "Hyper-V" and are more likely to be returned as such. I do not understand you talk about emperical testing, as our results across at least 4 different projects shows a different result from what you state.

The whole problem could be avoided by forcing strings.ToLower(moduleName) and this discussion would have been needless. However, we have "inherited" code from the upstream project and we sync what is available. We have noticed an inconsistency in the codebase and would like to move on. If you want to improve it, try to submit a PR to docker/machine or our https://github.com/machine-drivers/machine. At the moment, we prefer NOT to create a changed code inside vendor until we have moved tohttps://github.com/machine-drivers/machine

[AndrewSav]

The whole problem could be avoided by forcing strings.ToLower(moduleName)

Yes. That's what I meant. Glad we are finally on the same page. I was just saying that changing comparison of moduleName to "Hyper-V" to comparison of moduleName to to "hyper-v" is asking for trouble if we don't do strings.ToLower(moduleName) first.

Thank you for clearing this up!

[gbraad]

@AndrewSav I agree, but we have to important different codebases (aligning them) and also, finding a way that gives the most predictable result.

I'll propose a change to docker/machine first... but they do not make point releases

[rikkigouda]

+1 - I've got the same issue. Trying to look at the source codes and see if I can identify what's causing it.

[gbraad]

They have been informed on the official channel => http://kubernetes.slack.com/ (Use http://slack.k8s.io/ if you haven't signed up yet). It does not help to have another communication channel to discuss.

TL;dr: they have a missing commit from the libmachine codebase in 0.26.0, but @r2d4 did add this commit to 0.25.2

[dlorenc]

This should be fixed with #2719, in the main branch.

[gbraad]

Will there be a point release?

[pratikpparikh]

@dlorenc, similar to @gbraad I am wondering the same thing. As 0.26.0 allow the use of 1.10.0 and priors don't when is next dot release planned?

[rikkigouda]

@dlorenc why are we closing this issue? (At least a timeline on release would help?) I'm still facing this issue as one of the Hyper-V users. What's the plan for preventing this issue from coming back again?..

[AndrewSav]

@Goudarzi yeah, many projects for some reason close issues when some code changes were made in the main branch, but before a release happened and before the fix could be tested by the affected users. That's quite frustrating because from user's point of few it is NOT FIXED unless they can download a release and try it. With the issue closed tracking it's state becomes difficult. So I too wish, that issue are not closed until they actually resolved, or a statement is made that they are not going to be resolved at all.

[gbraad]

Re-opening until a release has been made and this has been tested by the OP or other Hyper-V users on this issue

[azalio]

Still have problem:

minikube version: v0.26.0
PS C:\Users\azalio> get-command hyper-v\get-vm

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


PS C:\Users\azalio> minikube start --vm-driver hyperv --hyperv-virtual-switch "minikube"
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
E0415 20:34:07.742269   14552 start.go:159] Error starting host: Error creating host: Error executing step: Running precreate checks.
: Hyper-V PowerShell Module is not available.

 Retrying.
E0415 20:34:07.744261   14552 start.go:165] Error starting host:  Error creating host: Error executing step: Running precreate checks.
: Hyper-V PowerShell Module is not available```

[gbraad]

As a workaround until a new version is released, try `Import-Module hyper-v` before using minikube

…

-- Gerard Braad | http://gbraad.nl [ Doing Open Source Matters ]

[m1o1]

Import-Module hyper-v didn't seem to work for me:

Starting local Kubernetes v1.10.0 cluster...
Starting VM...
E0416 09:59:32.849705    6828 start.go:159] Error starting host: Error creating host: Error executing step: Running precreate checks.
: Hyper-V PowerShell Module is not available.

 Retrying.
E0416 09:59:32.852150    6828 start.go:165] Error starting host:  Error creating host: Error executing step: Running precreate checks.
: Hyper-V PowerShell Module is not available

Edit* didn't notice the newline there, which gave it different behavior. I'll try that out.
Edit 2* nope, no luck.

[dlorenc]

I'll get a point release out today or tomorrow.

[Afshinzkh]

@dlorenc any update? I could not get any of the workarounds mentioned above to work. :(

[jordansissel]

I wanted to test this, but the build instructions do not seem to indicate how to build for windows.

That said, I managed to build it:

# from 258d1e149c5cbc50358749d90eccae4eef31c90f (master at time of writing)

# On linux, per build instructions:
% make

# Then copy the last `go build` command executed by `make` and prefix it with `GOOS=windows` and change the `-o` flag to `out/minikube-windows-amd64.exe`
GOOS=windows go build <...> -o out/minikube-windows-amd64.exe k8s.io/minikube/cmd/minikube

Then I copied this to my Windows machine, and ran it successfully:

> minikube --hyperv-virtual-switch=External --vm-driver hyperv start
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
Getting VM IP address...
Moving files into cluster...
Downloading kubeadm v1.10.0
Downloading kubelet v1.10.0
Finished Downloading kubelet v1.10.0
Finished Downloading kubeadm v1.10.0
Setting up certs...
Connecting to cluster...
Setting up kubeconfig...
Starting cluster components...

At this point in the output, I stopped watching because minikube start was already past the point where it crashed last time.

👍

[kierenj]

Looks good to me with the new release 👍

[gbraad]

Works as expected with the latest 0.26.1 release.

[d3rp3tt3]

Yes, the latest release is fine for me now.

[tarifrr]

Tried using Minikube 0.26.1 on Windows using Hyper-V, hangs once the VM is started and never gets assigned an IP and get the following error:

E0522 10:06:41.271060 39032 start.go:159] Error starting host: Error creating host: Error executing step: Provisioning VM.
: Temporary Error: provisioning: error getting ssh client: Error dialing tcp via ssh client: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

Tried other versions (0.27.0 and 0.26.0), and aren't starting up the cluster