-
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
macOS: Can't create minikube with xhyve #708
Comments
I'm having the same problem described above, as I've noted in #646. But I've tried both |
@zchee do you think this is the same UUID issue you've mentioned a few other times? |
@pquentin The exact same thing happens for me - for some reason, minikube decides to use the host as the DNS Server in this setup. See the |
@0ff Changed it to 8.8.8.8 but there's no change. I don't think it was using the host ip on my network though. What's surprising too is that I can ping google.com, and this requires DNS resolution, right? Hmm, so I just managed to create a minikube with xhyve + docker (not for mac). I think the only thing I did differently was to remove ~/.minikube. This appears to confirm what @mboersma said, Docker for Mac does not seem to actually change things here, so I'll remove that from the title. |
@dlorenc maybe yes. but short answer:
|
The reason for the hardcoded UUID was to try to get a consistent IP across restarts. Do you think that is still going to be possible? |
@jimmidyson Yeah, I know. But vmnet interface is not simply. Now I consider and research solution... |
And just question. |
I didn't... @chirino did iirc. |
@jimmidyson @dlorenc It might not relate, but macOS have original(?) UUID rules. (I think and maybe) When I use satori/go.uuid(or etc. google/uuid is same) for generate UUID, sometimes test is fail. This is why I have to generate a uuid using cgo. I think control of the UUID is should carefully. If we want to the same IP with no bugs, needs cleanup Edit: |
@zchee You're far more knowledgeable than me on this! I'm not even a mac user... but I'm really grateful for your investigation as it's affecting a number of users. I'm sure we can find quite a few testers of any fixes you propose. |
Note that in the original issue reported is not using the static UUID. Logging is different when the static UUID is used.
when the static UUID is used, you will see this in the logs instead.
|
@jimmidyson oh, thanks :) I'll do my best. @chirino Yes, and other issue thread have same bug. I'll create repository that sample and simple UUID convert script written Go later. |
@r2d4 Got it. thanks. maybe caused by vmnet internal process or conver(search) IP from dhcpd_leases. |
FYI i've run into a similar issue in the past. What I did wrong was trying to build docker-machine-driver-xhyve using plain go get. Builds fine but it does not work. You HAVE to build with make. |
@chirino Ah, good information. I'll also check the go get plain build binary behavior. |
@pquentin and small reply
It means use Docker for Mac only? If so, It might solve with
It might is associated as well with this problem. |
@zchee Thanks! It does not appear to help though. I hope I did that correctly. As I was saying, it turns out that there's no longer a difference between Docker for Mac and Docker. Maybe because I now remove ~/.minikube each time. (I also hope that it was really Docker and Docker for Mac above, because docker -v now returns something different for the two versions. I can produce the logs again if that would help.) The minikube creation itself is no longer a problem for me: I would be happy to close this issue, but it looks like it's now bigger than me. :) |
I've been doing this as @zchee suggested.
Unfortunately, yes, at least for me and a couple coworkers. Using xhyve and $ minikube start --logtostderr --show-libmachine-logs --vm-driver=xhyve
I1024 14:19:39.583187 22679 notify.go:111] Checking for updates...
Starting local Kubernetes cluster...
I1024 14:19:39.816177 22679 cluster.go:79] Machine exists!
I1024 14:19:39.836294 22679 cluster.go:86] Machine state: Running
Waiting for SSH to be available...
E1024 14:22:39.968309 22679 start.go:90] Error starting host: Error configuring auth on host: %s: Temporary Error: Too many retries waiting for SSH to be available. Last error: Maximum number of retries (60) exceeded. Retrying.
E1024 14:22:39.968418 22679 start.go:96] Error starting host: Error configuring auth on host: %s: Temporary Error: Too many retries waiting for SSH to be available. Last error: Maximum number of retries (60) exceeded I've also tried with and without the "regenerate UUID" patch to the xhyve driver, but it doesn't seem to matter. |
@mboersma Sorry for the delay. I was some debug and research However, found a good debugging way. open -a Console.app and re-try If you are confused by many of the logs, add to search dialog.
Please try it and tell me the error log. In my case, I was tested case of have not Ultimately, I found that internet sharing was processed in the
|
I have the same output as @mboersma. |
Here is my console log https://gist.github.com/adamreese/a82c10b39b438de7328cbc7f475aa61f |
@adamreese Thanks for detail log! |
Like I already mentioned in #646 this is now solved in my system with some latest updates. Not sure which one actually fixed it, but my current versions are:
|
It's not working for me. In Console.app I see: docker-machine-driver-xhyve[982] invalid client in the minikube log: (minikube) Convert UUID to MAC address... |
Hi, I followed these steps:
minikube failed to start " Retrying.
|
rm -rf ~/.minikube minikube start --vm-driver=xhyve This helped resolve my issue: $ minikube start --vm-driver=xhyve |
$kubectl run hello-minikube --image=grc.io/google_container/echoserver:1.4 --port=8080 Error: failed to discover supported resources: Get https://192.168.99.100:8443/api: dial tcp 192.168.99.100:8443: i/o timeout Can you please help me how to resolve this ? |
Yes it worked for me as well. Please follow the same order. sudo rm -rf ~/.minikube |
I'm having this same problem with both minikube and docker-machine using the docker-machine-driver-xhyve 0.33 release. The problem began happening after i upgraded from minikube 0.25.0 to minikube 0.25.2. The solution above does not resolve the issue. I've emptied the dhcpd_leases file and ensured permissions are set appropriately to no avail. Please help. Thanks. |
Minikube version (use
minikube version
): 0.11.0Environment:
cat ~/.minikube/machines/minikube/config.json | grep DriverName
): xhyvedocker -v
): Docker version 1.12.2, build bb80604 installed through homebrewWhat happened:
My team uses Kubernetes in production and we recently decided to switch local development from docker-compose to minikube. Their migration went well, but not mine. I tried to create a minikube cluster like this:
As you can see from the shortened logs, this does not work.
What you expected to happen:
I expected cluster creation to work. What's strange is that it does work after installing Docker for Mac using
brew cask install docker
(and notbrew install docker
). But it's the same Docker version!(I think it would have worked with Docker Toolbox too.)
How to reproduce it (as minimally and precisely as possible):
Update: While the steps were completely reproducible for me, they no longer are, see #708 (comment)
Anything else do we need to know:
curl google.com
: it timeouts (separate issue but I thought I should mention it).The text was updated successfully, but these errors were encountered: