minikube: hyperv: minikube stuck at "Waiting for SSH access ..."

When i start my minikube cluster i have these logs,

$ minikube start
o   minikube v0.34.1 on windows (amd64)
i   Tip: Use 'minikube start -p <name>' to create a new cluster, or 'minikube delete' to delete this one.
:   Re-using the currently running hyperv VM for "minikube" ...
:   Waiting for SSH access ...

And it stuck at waiting for SSH access. I use hyper V and when i connect to the vm the minikube cluster start successfully but in my console don’t show it. If i kill the command and i try to run minikube delete i have these logs

$ minikube delete
-   Powering off "minikube" via SSH ...

And the command stuck at “Powering off “minikube” via SSH …”

Im using: Windows v1809 minikube v0.34.1

Thank you in advance for your help !

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 17
  • Comments: 26 (3 by maintainers)

Most upvoted comments

On macOS with minikube version 1.0.0, upon a hanging

Waiting for SSH access ...

it was enough to do

^C                           # interrupt
minikube delete     # delete minikube from virtualbox and detele cluster
minikube start

to get a working minikube.

Why is this issue even closed? I try to install minkube on Windows 10 today, and I’m still stuck here after 8 hours.

First, it’s this one.

[stderr =====>] :
Using SSH client type: native
&{{{<nil> 0 [] [] []} docker [0x8359b0] 0x835980  [] 0s} 192.168.1.104 22 <nil> <nil>}
About to run SSH command:
exit 0
Error dialing TCP: dial tcp 192.168.1.104:22: connectex: No connection could be made because the target machine actively refused it.

I read a lot of articles, and try to stop and start adaper, try to change Virtaul Swtich Connection type from External network to private, try to change External network from Wi-Fi to ethernet.

[stderr =====>] :
Using SSH client type: native
&{{{<nil> 0 [] [] []} docker [0x8359b0] 0x835980  [] 0s} fe80::215:5dff:fe73:bb03 22 <nil> <nil>}
About to run SSH command:
exit 0
Error dialing TCP: dial tcp [fe80::215:5dff:fe73:bb03]:22: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

None of those work. Then I try to delete minikube to try a new minikube VM, then I cannot stop it. I cannot delete it. I cannot even shut it down from Hyper-V Manager. I have to reboot into Safe-Mode just to delete C:\Users\USER\.minikube to go back and create minikube from start AGAIN.

I have been using docker on Ubuntu for years, and I couldn’t imagine how windows users are going to use something like this. After trying to run minikube on windows for 8 hours, I am just very frustrated.

After performing the naming, you can start it. But this operation looks stupid

rm -rf ~/.minikube/machines/minikube/hyperkit.pid

Heavy scene: Instead of shutting down the minikube via minikube stop, it forces the computer to power off. Then the error occurs in minikube start.

@matthiasg This bundle image

Requiring a minikube delete everytime there is a minikube stop is not a valid solution. What’s causing this?

did all the hard things first but a restart after having used CiscoVPN a couple weeks ago is what cleared the minikube startup problem I was having (“Waiting for SSH access …”).

A Mac host restart cleared the problem for me and this seems like a significant clue to the problem… Maybe my Mac’s networking state was in an unexpected configuration as a result of running CiscoVPN. Other’s have reported success after doing upgrades, downgrades, reinstalls, et cetera, but I’m wondering if they did not realize that they did other things that might have also had an effect on curing their problem… like rebooting or sleeping (I have done neither for almost a month).

But i finally decide do use the kubernetes inegration bundle with the docker desktop app because it it is more simple to use than minikube and it has less issues

I believe I found the workaround/solution. I had a flashback about similar situation I had with Docker some time ago. The root cause seems to be Windows Firewall, which by default treats Hyper-V virtual switches as an untrusted network. The solution is to switch its category to private, with the following PowerShell command (you must run PowerShell with admin rights), presuming your virtual switch for minikube is called “minikube”:

Set-NetConnectionProfile -interfacealias "vEthernet (minikube)" -NetworkCategory Private

You probably have to repeat it after each Windows update, because this change doesn’t seem to persist after such updates.

P.S. I wasn’t able to make things work in general due to another error further down the road (I should probably file another issue for it), but at least I’ve unblocked this general connectivity issue between host and VM.

Hope this helps.

This is the outpout of minikube start --alsologtostderr -v=8

I0222 19:36:30.141247    6412 notify.go:121] Checking for updates...
o   minikube v0.34.1 on windows (amd64)
I0222 19:36:30.171247    6412 start.go:579] Saving config:
{
    "MachineConfig": {
        "MinikubeISO": "https://storage.googleapis.com/minikube/iso/minikube-v0.34.0.iso",
        "Memory": 2048,
        "CPUs": 2,
        "DiskSize": 20000,
        "VMDriver": "hyperv",
        "ContainerRuntime": "docker",
        "HyperkitVpnKitSock": "",
        "HyperkitVSockPorts": [],
        "XhyveDiskDriver": "ahci-hd",
        "DockerEnv": null,
        "InsecureRegistry": null,
        "RegistryMirror": null,
        "HostOnlyCIDR": "192.168.99.1/24",
        "HypervVirtualSwitch": "MinikubeNAT",
        "KvmNetwork": "default",
        "DockerOpt": null,
        "DisableDriverMounts": false,
        "NFSShare": [],
        "NFSSharesRoot": "/nfsshares",
        "UUID": "",
        "GPU": false
    },
    "KubernetesConfig": {
        "KubernetesVersion": "v1.13.3",
        "NodeIP": "",
        "NodePort": 8443,
        "NodeName": "minikube",
        "APIServerName": "minikubeCA",
        "APIServerNames": null,
        "APIServerIPs": null,
        "DNSDomain": "cluster.local",
        "ContainerRuntime": "docker",
        "CRISocket": "",
        "NetworkPlugin": "",
        "FeatureGates": "",
        "ServiceCIDR": "10.96.0.0/12",
        "ExtraOptions": null,
        "ShouldLoadCachedImages": false,
        "EnableDefaultCNI": false
    }
}
I0222 19:36:30.173248    6412 cluster.go:75] Skipping create...Using existing machine configuration
i   Tip: Use 'minikube start -p <name>' to create a new cluster, or 'minikube delete' to delete this one.
[executing ==>] : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM minikube ).state
[stdout =====>] : Running

[stderr =====>] :
I0222 19:36:30.558261    6412 cluster.go:94] Machine state:  Running
:   Re-using the currently running hyperv VM for "minikube" ...
I0222 19:36:30.558261    6412 cluster.go:112] engine options: &{ArbitraryFlags:[] DNS:[] GraphDir: Env:[] Ipv6:false InsecureRegistry:[10.96.0.0/12] Labels:[] LogLevel: StorageDriver: SelinuxEnabled:false TLSVerify:false RegistryMirror:[] InstallURL:}
:   Waiting for SSH access ...
Waiting for SSH to be available...
Getting to WaitForSSH function...
[executing ==>] : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive ( Hyper-V\Get-VM minikube ).state
[stdout =====>] : Running

[stderr =====>] :
[executing ==>] : C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive (( Hyper-V\Get-VM minikube ).networkadapters[0]).ipaddresses[0]
[stdout =====>] : 192.168.1.46

[stderr =====>] :
Using SSH client type: native
&{{{<nil> 0 [] [] []} docker [0x8359b0] 0x835980  [] 0s} 192.168.1.46 22 <nil> <nil>}
About to run SSH command:
exit 0
Error dialing TCP: dial tcp 192.168.1.46:22: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

And i don’t think is a network switchproblem because my network switch is well configured image