-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make xhyve default for OSX #270
Comments
FYI I've made xhyve, kvm, hyperv default for OS X, Linux, Windows respectively on a fork (https://github.com/jimmidyson/minishift) & all works great. Some issues related to setting up binaries but nothing any different from having VirtualBox installed & configured... |
Is it possible to pass flags to docker-machine-driver-xhyve? |
Not right now, which flags are you trying to pass? On Thu, Aug 11, 2016, 4:49 PM William Bert notifications@github.com wrote:
|
I'd beef up xhyve a bit, something like: |
Ah, you can just use our standard CPU and memory flags, those will go to the driver. |
Great, thanks! |
Do you guys enable --xhyve-experimental-nfs-share by default? If not, is there a way to enable it? |
@justechn no, we don't expose it or enable it. @aaron-prindle is working on a cross platform nfs solution tracked by #1033. In the meantime, if you really want to set up an nfs mount on OSX, you can follow some of the instructions here #2 (comment) |
I recommend against making xhyve the default driver. For me trying to get xhyve to work reliably has been a big pain in the rear. There have been numerous fixes put into xhyve, but getting zchee to cut new releases is proving difficult. There is also a networking issue that is blocking some, including me from being able to use it machine-drivers/docker-machine-driver-xhyve#107. Virtualbox may not be as performant, but it works a lot more reliably, and for a default driver I think that is the most important. Personally I would rather see more effort put into the no driver options. I think running minikube in local docker is a much better idea |
@justechn how do you mean local docker? Unless I'm misunderstanding something, the "none" driver only really makes sense on Linux (and possibly Illumos), which can natively run Linux containers with namespace/cgroup support built into the kernel. macOS has no such support and as such needs some sort of VM to run Linux. |
I was hoping that was not the case. Oh well... |
Yeah, unfortunately containers are basically a special way to run a process (tree) on linux, where you can say "I want this process I'm launching to have a distinct view of processes, filesystems, network devices, users, and some assorted other stuff; also I want to control its lifecycle/resource consumption". The first half of that is namespaces and the second half of that is cgroups, and macOS has neither of those mechanisms. It does have a distinct kernel sandboxing mechanism that gives you some of the benefits, but given that all container mechanisms out there assume Linux, if you tried to download and run a Docker container (even isolated using the sandbox mechanism), the macOS kernel would just say "I don't know how to run any of the binaries in here". |
Question: What are the benefits of xhyve over VirtualBox? The main comparison I've found is here: https://thepracticalsysadmin.com/xhyve-vs-vbox-driver-benchmarks-for-docker-machine/ It's a bit dated at this point (Feb 2016), but suggests VirtualBox has comparable and potentially better performance. Do we have more recent/higher quality evidence that xhyve yields better performance, reliability, etc? Or is switching to xhyve just about simplifying installation/maintenance? For context: I'm trying to reduce the runtime of a bunch of tests executing in a minikube environment, and am considering swapping from the vbox to the xhyve driver, but haven't found any benchmarks suggesting it will actually improve performance. |
@jgiles The TLDR is that |
This should probably be updated to say "Make hyperkit the default for OSX" since that is the current recommendation. |
Also, as a followup to #270 (comment) above: I tried xhyve for a while, and at least in my case there was a very noticeable loss of performance relative to VirtualBox. Before switching the default, it would be good to get some performance metrics for minikube workloads on each of the drivers. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Rotten issues close after 30d of inactivity. Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
This is still something that needs to be reviewed. |
What’s the current recommendation for best experience (I don’t mind minor stability issues)? vbox/xhyve/hyperkit? |
After #248 lands, we'll have these remaining tasks for xhyve support are:
The text was updated successfully, but these errors were encountered: