Add xhyve driver support #248
Conversation
|
Nice! I'll give this a try later tonight. |
| @@ -84,6 +85,18 @@ Download the `docker-machine-driver-kvm` binary from | |||
| https://github.com/dhiltgen/docker-machine-kvm/releases and put it somewhere in | |||
| your PATH. Minikube is currently tested against `docker-machine-driver-kvm` 0.7.0. | |||
|
|
|||
| #### xhyve driver | |||
There was a problem hiding this comment.
I'd prefer to split out all driver instructions to a separate doc
There was a problem hiding this comment.
Pulled out into DRIVERS.md & linked appropriately (hopefully).
|
works for me ;-) |
|
Thanks for the feedback @rhuss! |
|
Sorry, haven't had a chance to try this yet. I definitely will later tonight. |
| * [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [VMware Fusion](https://www.vmware.com/products/fusion) | ||
| or [KVM](http://www.linux-kvm.org/) installation | ||
| * [VirtualBox](https://www.virtualbox.org/wiki/Downloads), [VMware Fusion](https://www.vmware.com/products/fusion), | ||
| [KVM](http://www.linux-kvm.org/) or [xhyve](https://github.com/mist64/xhyve) installation |
There was a problem hiding this comment.
I got this running, and I don't have xhyve itself installed as far as I can tell. Maybe clarify that you just need the driver, not xhyve itself?
There was a problem hiding this comment.
Ah thanks for the clarification. Will update docs later.
There was a problem hiding this comment.
Updated - hope it reads OK.
|
Nice, this seems to work great! I'm going to see if I can merge in the changes from https://github.com/zchee/boot2docker-legacy/releases as well, so we can get virtio-9p support too :) |
| The following drivers currently require driver plugin binaries to be present in | ||
| the host PATH: | ||
|
|
||
| * [KVM](#kvm-driver) |
There was a problem hiding this comment.
Can these be bundled into minikube?
There was a problem hiding this comment.
As discussed in other issues, that is the goal but there some outstanding problems with the xhyve driver atm. #262 adds embedded KVM driver for Linux & the same technique can be used for xhyve once we've sorted the driver issues.
|
@dlorenc Why are we choosing to support multiple drivers instead of choosing the best one and supporting just that? Do regular users care? Is |
|
At-least just one driver per OS and support just that. |
|
@vishh Who decides what is the best driver for an OS? Understand the test matrix issue, perhaps allowing users to use various drivers but documenting the fully tested drivers would be enough, others being noted as best effort? And yes, IMO, regular users do care: e.g. some have an almost pathological hatred of vbox, others love it... that's not power users, just familiarity with particular technology. I think we're really lucky to have the underlying docker machine to build on top of as that should hopefully allay some (most?) compatibility concerns. |
|
My 2 cents: I don't want to support dozens of drivers, the test-matrix would get huge. I think it's fine to have a small number of them though, especially as an experimental feature. We should pick the "best" driver for each OS and make it default. Right now Virtualbox is an easy choice because it's free and cross platform, but long term I think we'll probably want something like: OSX: xhyve/hyperkit Eventually, we should aim to bundle these inside minikube, and not require users to install another binary. Some of these drivers don't look maintained anymore, so we should pick up maintenance of them if the authors don't mind. But these drivers will take some work before we can really bundle them into minikube and make them as stable/easy to use as virtualbox, so we'll need to keep them behind a flag until we get them fully ready. We should agree on a policy here though and document it on our README. Adding dozens of drivers wouldn't be good for the maintainers or the users. |
|
+1 to compiling in drivers, but agree it will take some investigation to figure out how to override the docker machine fork/RPC approach for non core drivers. That looks like the best drivers to support. Personally I've experienced so many problems with virtualbox in the past that I'd prefer to avoid it, hence my attempts to support KVM & xhyve (which are both free/oss too of course). |
|
I think @dlorenc summarized my thoughts more effectively. When this project started virtualization was never meant to be exposed to end users. That way if we pivot to using docker directly in the future for example, we need not worry about breaking existing users. I'm not suggesting not adding |
|
+1 on dropping vbox ASAP, but I think this is a good step forward. Looking through the code, docker-machine-driver-xhyve is a bit out of date and vendors in some out of date copies of lib9p and xhyve. We should clean up the dependencies and build process before making this the default. This LGTM now, I'll wait to merge though to make sure everyone agrees with this approach. |
|
+1 to dropping vbox in favour of embedded xhyve driver (when we figure out how) for OS X. Opened #261 to discuss platform default virt providers. |
|
Merging this now. Opened #270 to track the remaning xhyve work. |
|
How does one choose xhyve over virtualbox (I'm on a mac) |
|
We have some documentation on the various drivers here: https://github.com/kubernetes/minikube/blob/master/DRIVERS.md |
|
One thing I don't think it specifies is to add |
As I don't run OS X this is untested, but I know a number of OS X users who
prefer xhyve to virtualbox. Looking for volunteers to test. @jstrachan?