VirtualBox on VMware: Creating VM, max retries exceeded (connect: connection refused)

[arijitjph]

So, I am trying to install minikube on my laptop. I have a windows 7 machine on which I have installed VMware work station and created a centos 7 machine. On that centos machine I want to install minikube. I have followed few steps and installed all the dependencies but finally # minikube start is giving error

[root@localhost ~]# minikube start --vm-driver=virtualbox SERVICE_CLUSTER_IP_RANGE="X.X.X.X/24" --container-runtime=docker --extra-config kubelet.EnableCustomMetrics=true There is a newer version of minikube available (v0.33.1). Download it here: https://github.com/kubernetes/minikube/releases/tag/v0.33.1

To disable this notification, run the following: minikube config set WantUpdateNotification false Starting local Kubernetes v1.8.0 cluster... Starting VM... Downloading Minikube ISO 140.01 MB / 140.01 MB [============================================] 100.00% 0s

E0214 04:21:19.799121 16837 start.go:150] Error starting host: Error creating host: Error executing step: Creating VM. : Maximum number of retries (5) exceeded.

Retrying. E0214 04:21:19.813063 16837 start.go:156] Error starting host: Error creating host: Error executing step: Creating VM. : Maximum number of retries (5) exceeded

[tstromberg]

Do you mind first upgrading to minikube v0.33.1? This version seems rather old.

[arijitjph]

This is the error I am getting now 👍

[root@localhost ~]# minikube start --vm-driver=virtualbox SERVICE_CLUSTER_IP_RANGE="X.X.X.X/24" --container-runtime=docker --extra-config kubelet.EnableCustomMetrics=true
Starting local Kubernetes v1.13.2 cluster...
Starting VM...
E0214 06:03:32.618467 24188 start.go:205] Error starting host: Error starting stopped host: Maximum number of retries (5) exceeded.

Retrying.
E0214 06:03:32.621780 24188 start.go:211] Error starting host: Error starting stopped host: Maximum number of retries (5) exceeded

minikube failed :( exiting with error code 1
[root@localhost ~]#

[tstromberg]

OK. We've definitely failed to provide useful output there. What's it say if you add --alsologtostderr -v=8 to the command-line?

[arijitjph]

Here I get when added "--alsologtostderr -v=8"

TDERR:
{
}
COMMAND: /usr/bin/VBoxManage startvm minikube --type headless
STDOUT:
{
Waiting for VM "minikube" to power on...
VM "minikube" has been successfully started.
}
STDERR:
{
}
Checking vm logs: /root/.minikube/machines/minikube/minikube/Logs/VBox.log
Waiting for an IP...
Getting to WaitForSSH function...
Using SSH client type: native
&{{{ 0 [] [] []} docker [0x83a9a0] 0x83a970 [] 0s} 127.0.0.1 35606 }
About to run SSH command:
exit 0
Error dialing TCP: ssh: handshake failed: read tcp 127.0.0.1:54138->127.0.0.1:35606: read: connection reset by peer
Error dialing TCP: dial tcp 127.0.0.1:35606: connect: connection refused
Error dialing TCP: dial tcp 127.0.0.1:35606: connect: connection refused
Error dialing TCP: dial tcp 127.0.0.1:35606: connect: connection refused
Error dialing TCP: dial tcp 127.0.0.1:35606: connect: connection refused
Error dialing TCP: dial tcp 127.0.0.1:35606: connect: connection refused
Error dialing TCP: dial tcp 127.0.0.1:35606: connect: connection refused

[tstromberg]

Thanks for the additional input. It appears that VirtualBox is creating a VM, but not able to SSH to it, though I'm not sure why. It's possible that it's because you are running minikube and VirtualBox as root, which is not recommended.

Do you mind trying with minikube v0.34 and a non-root user? If it still fails, please attach full --alsologtostderr -v=8 log by dragging it into the content box?

If it doesn't work out, it's probably that the kvm2 driver will not fail in the same way.

[tstromberg]

Also, once you do get it to work, know that while it may just work, Kubernetes v1.8.0 is no longer a supported release: https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#supported-releases-and-component-skew

At the moment, the oldest officially supported Kubernetes release is v1.11.7.

[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

[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!