HyperV Hung at "Starting cluster components..."- connectex: Connection Denied

[DarkGhostHunter]

BUG REPORT

Minikube version: v0.28.0

• OS: Windows 10 Pro x64 1803
• VM Driver: Hyper-V
• ISO version: v0.28.0

What happened:

Created an Internal Network Switch on HyperV. minikube executed using:

minikube start --vm-driver hyperv --hyperv-virtual-switch "NetworkSwitch"

After completing all the steps, it hangs on:

Starting cluster components...

Hyper-V shows the VM with 0% usage after a while. Issuing a shutdown signal hangs up the VM for several minutes, blocking even a disconnect (Windows says It cannot disconnect the machine).

minikube commands also become unresponsive. minikube logs hangs up or takes several minutes to display log messages. Even using -f. The only way to kill the machine is to connect directly via Hyper-V, login as root, and issue a shutdown -P.

What you expected to happen:

To NOT hang up. To keep being responsive.

How to reproduce it:

1. Fresh install minikube an kubectl from chocolatey.
2. Enable Hyper-V if necessary.
3. Create an Internal Network Switch in Hyper-V.
4. Disable IPv6 on the Internal Switch.
5. Run minikube start --vm-driver hyperv --hyperv-virtual-switch "NetworkSwitch", being the NetworkSwitch the real name of the latter.
6. Look how it hangs.

Output of minikube logs

Only this:

Error getting cluster bootstrapper: getting kubeadm bootstrapper: getting api client: Error loading host from store: open C:\Users\DevOps2\.minikube\machines\minikube\config.json: The system cannot locate the resource specified.

And this when using -v 5

I0713 00:41:01.649216    6844 kubernetes.go:119] error getting Pods with label selector "k8s-app=kube-proxy" [Get https://[fe80::215:5dff:fe01:173]:8443/api/v1/namespaces/kube-system/pods?labelSelector=k8s-app%3Dkube-proxy: dial tcp [fe80::215:5dff:fe01:173]:8443: connectex: Connection Denied]

Anything else do we need to know

• Using --bootstrapper=localkube works, but using minikube stop hangs out the power off processes (sames a above).

[InbarRose]

I have the same issue, I was following instructions here: minikube-on-windows-10-with-hyper-v

I even performed the extra fixes (removed dynamic memory, and removed IPv6)

get this, (hundreds of this line):
I0717 13:08:20.394237 9652 kubernetes.go:119] error getting Pods with label selector "k8s-app=kube-proxy" [Get https://192.168.0.13:8443/api/v1/namespaces/kube-system/pods?labelSelector=k8s-app%3Dkube-proxy: dial tcp 192.168.0.13:8443: connectex: No connection could be made because the target machine actively refused it.]

And then at the end I get this:
E0717 13:08:20.394237 9652 start.go:299] Error restarting cluster: restarting kube-proxy: waiting for kube-proxy to be up for configmap update: timed out waiting for the condition

[InbarRose]

@DarkGhostHunter Using --bootstrapper=localkube does work. Thanks for this tip, where did you figure this out?

[tpischke-bedag]

I have the same issue with Windows 7 and VirtualBox with chocolately installed minikube

[tstromberg]

For what it's worth, I'm pretty sure this is representative of a HyperV virtual switch issue, but also possibly a firewall issue. Do you mind attaching the output of:

minikube --v=7 start --vm-driver hyperv --hyperv-virtual-switch "NetworkSwitch"

NOTE: This will likely be a large logfile.

[gbraad]

No connection could be made because the target machine actively refused it.

This is likely related to a firewall (or antivirus) software

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: You can't close an active issue/PR unless you authored it or you are a collaborator.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tstromberg]

I'm closing this issue as it hasn't seen activity in awhile, and it's unclear if this issue still exists. If this issue does continue to exist in the most recent release of minikube, please feel free to re-open it.

Thank you for opening the issue!