Minikube: Start failed on WSL

[itanoss]

Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST

Please provide the following details:

Environment:

Minikube version (use minikube version):

• OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS as WSL in Windows 10
• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName): hyperv

What happened:
minikube cannot start on WSL.

What you expected to happen:
minikube support hyper-v on Windows machine regardless of shell environment.

How to reproduce it (as minimally and precisely as possible):
Install Hyper-V on Windows machine as well as WSL (Windows Subsystem as Linux). After following your instruction to install minikube in bash session, try minikube start.

Output of minikube logs (if applicable):

$ minikube start --vm-driver hyperv
Starting local Kubernetes v1.8.0 cluster...
Starting VM...
panic: hyperv not supported

Anything else do we need to know:

[gbraad]

Closing this issue as this is currently not possible with the current WSL/LXSS environment. This is an unsupported usecase, as the WSL environment will start a Linux compatible environment and has no direct access to the Windows executables and drivers. Therefore you can not start or interact with HyperV. The executable thinks you are on Linux and will only allow KVM and VirtualBox to be used, but even if allowed it will not be able to perform the request interaction with the HyperV API.

Please note, WSL/LXSS is not a shell environment, but a compatibility layer to run unmodified Linux ELF libraries and executables. The name should have been "Ubuntu environment on Windows 10" as the Bash shell is a misnomer in this case. A bash for Windows is available in the form of git-bash and cygwin (and these do interact directly with the local environment), however even these have issues yo interact as all API calls with HyperV needs a PowerShell shell instance to be created in the background.

Even though the Creators update addresses the invocation of Windows binaries inside the WSL environment significant rewrites would be needed to make this work from the binary, with a minimal payoff (this needs to be added to the linux binary, additional testing is needed; setup of CI). Maybe doing cmd.exe /c minikube.exe --vm-driver=hyperv could work instead as a workaround. See for more info: https://github.com/Microsoft/WSL/issues/333#issuecomment-287789180 Correction: just use the Windows binary directly by either putting it on your path or cd to it, cd /mnt/c/Users/gbraad/Downloads; minikube.exe start --vm-driver=hyperv.

Note: you can start minikube-windows outside WSL/LXSS, using PowerShell or the Command Prompt, and use a Linux compiled version of kubectl inside the environment to interact with the Kubernetes cluster. This is how I do some of the tests for Minishift (minikube-related fork for OpenShift) and worked on the Fedora port to WSL/LXSS.

[gbraad]

Correction: invoke the Windows binary instead:

$ cd /mnt/c/Users/gbraad/Downloads; minikube.exe start --vm-driver=hyperv

Note: be sure you run the Creators update (and not the Anniversary update) of Windows 10

[djensen47]

I'm a little confused. So should it or should it not work?

From WSL, I tried...

$  minikube.exe start --vm-driver=hyperv  --hyperv-virtual-switch=Minikube

and got an error

Starting VM...                                                                                              
E0107 23:10:45.267589   15364 start.go:150] Error starting host: Error starting stopped host: exit status 1.

 Retrying.                                                                                                  
E0107 23:10:45.268589   15364 start.go:156] Error starting host:  Error starting stopped host: exit status 1

It's a bit of a hassle settings up kubectl to run in WSL (changing the configuration manually whenever the IP changes) and I _really_ need to be able run `minikube docker-env from within WSL. Thanks.

[gbraad]

Test first if you can start minikube from powershell or a command prompt. The error itself does not look like related to WSL at all.

If needed, just use DOCKER_HOST from the WSL environment instead. This is a simple copy-paste action away.

However, it best to avoid WSL entirely. I still think a lot of stuff is quirky and unpredictible... I only use it for starting a SSH session to either a VM or starting a container in either minishift/minikube or mobylinux.

[djensen47]

Yeah, minikube runs just fine from powershell.

[djensen47]

I need WSL to be able to write Makefiles for deployments both locally and remote. The copy and paste operation is easy but it's not scalable to a team of more than one. 😕

[gbraad]

WSL is not an official supported environment to begin with, so it means you will have to resort to the less scalable alternative.

I can guess what error means, as likely there is a mismatch between the HOME, which causes it to think the host is not in the right state. I might have a look at this later, but it is to be honest very far down my list of priorities. Especially, as a workaround is possible... set DOCKER_HOST

To be able to use Makefiles you can also use Cygwin after adding it to your path; this also allows you to call minikube (without having to state .exe), as you just run the Makefile from a command prompt.

[djensen47]

Thanks, that actually got me digging around and I had two .minikube dirs so I clobbered both of them and tried again and it worked. I just had to reset all of my minikube environments.

[gbraad]

👍

[therazor]

In case anybody else got stumped by this, there's a walkthrough to get minikube to (kinda) play nice with WSL