-
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
Decide supported virtualization providers #261
Comments
That list sounds good to me. For Linux we might also want a "no vm" option, eventually. |
The KVM driver is currently missing a LICENSE. I just opened an issue to track that. We'll need a LICENSE before we can bundle: dhiltgen/docker-machine-kvm#17 |
I see the original author of #220 didn't comment, so I'll chime in here that supporting whatever drivers are already supported by docker-machine would be a solid +1 from me. Not everyone wants the xhyve virtualization integration (myself being one of them) as its extremely nice to manage VM's with my existing tools. I can confirm that the parallels provider has been stable and a good user experience when testing docker-machine and other infra/container related tech. I get better battery life out of my rig when using Parallels vs VirtualBox, and even xhyve. That alone makes this worth it to me as i'm a road warrior. I'll gladly donate time/effort to see this to completion. |
Closing this: I think we've settled upon virtualbox |
Hmm a support for parallels would probably be very welcomed as this is probably the most used virtualization system on OS X (The best integration with the system and as far as I know the best performances). Also, it's supported on Docker-machine with an external plugins: https://github.com/Parallels/docker-machine-parallels |
|
I have patches for parallels support that work well as far as I can tell (the changes are quite minor). I see that the issue was closed without including parallels in the supported list, but would a PR change your mind? I've just submitted a CLA. |
Is there a separate issue for tracking the possibility of running kubernetes natively on Linux without the extra VM layer? https://news.ycombinator.com/item?id=12044317 links here but this issue is closed now. I've been using https://github.com/kubernetes/kubernetes/blob/master/docs/devel/local-cluster/docker.md to run Kubernetes natively using just containers but that guide now recommends using Minikube, ironically. :) |
@TylerRick I don't believe there's an issue made. Definitely something on our roadmap though. |
Thanks for the update, @r2d4. I do see "Remove hypervisor on Linux systems" on https://github.com/kubernetes/minikube/blob/master/ROADMAP.md now so that's encouraging 👍 |
Like many other people here i'm using parallels desktop virtualization on OS X. Is there a way to include it's support, like https://github.com/ahobson/docker-machine-parallels? |
For those wondering about progress on Linux native container support, see this query for "no-vm" in issues. |
I can't find any issue for Linux native support. @gwicke, your query doesn't return anything relevant? |
Interesting: a7c2ff3 |
+1 for parallels, it'd been a phenomenal find in my workflow, is pretty robust, and does manage battery life very well! Please add support! |
+1 to Parallels support for OSX. +1 on battery life! Not sure how VMWare Fusion was selected but I believe parallels is the dominant VM product on OSX. Happy to help make this happen. |
+1 to Parallels support for OSX. battery life and just nicer to deal with. |
+1 for Parallels! the fork with parallels working is already there and the request is being made by lots of people over 2 years period. This is 2 years of pure bureaucracy. |
@joadr : did you have an updated PR for the Parallels driver support ? |
Never mind, found it in the linked issues. Basically requesting support for whatever docker-machine supports... Quite similar to our current “generic” discussion. I guess that @tstromberg can help arbitrate, in what drivers are finally allowed to be “supported” by minikube ? |
As discussed in #248, we should limit the supported virt providers. Let's decide so we can target embedding the drivers required rather than fork/RPC the plugin binaries as we're doing now.
My suggestions for defaults:
We should perhaps also consider virtualbox as it is supported on all above platforms AFAIK & might be a decent fallback which still limits the size of test matrix?
The text was updated successfully, but these errors were encountered: