docker-machine-driver-xhyve
docker-machine-driver-xhyve copied to clipboard
machine-drivers
Use official go wrapper
As of https://github.com/docker/hyperkit/pull/104 (which just got merged), Hyperkit has its own "official" go wrapper, which would probably be simpler to use/maintain than the one in this project.
@copumpkin Yeah, I considered and saw this binding.
I think hyperkit has been provided binary call API for third-party is great. but I thought, It's just binary wrapper call, so required installing the "Docker for Mac" Application.
Currently, this project is no dependency except vendor package. So if users (of curse, I'm already installed Docker for Mac) not like, or not installed "Docker for Mac", docker-machine-driver-xhyve become can't work.
However, maintain the libhyperkit needs very higher cost. really. So, now I don't know which is better way.
/cc @dlorenc @r2d4 What do you think about it?
I think we should probably switch to the wrapper. They just added support for vmnet networking, which was missing before and required by this.
Another thing that might be worth investigating is that the suid bit is only needed for vmnet networking, so if we can switch to e.g., VPNKit (i.e., map to unprivileged ports, etc.), we could get away with no superuser privileges, at least in some cases. For me at least that's been a fairly annoying sticking point of using this stuff.
@dlorenc OK, I’ll check official go wrapper internal. And will try to rewrite xhyve-driver all logic.
But, it means we can’t static build to hyperkit C source.(libhyperkit) It depends on hyperkit binary(AFAIK)
So this driver users needs build hyperkit from source, or install Docker for Mac. That is a matter of concern.
What do you think about it?
@copumpkin Thanks comment. Sorry, now time for bed in Japan. I’ll comment tomorrow.
Have a good night :)
Hyperkit is now packaged in brew: https://github.com/moby/hyperkit/issues/119
Perhaps we could depend on it that way, from the brew package for docker-machine-driver-xhyve.
@dlorenc Thanks :)
Oh, that’s good news. OK, I’ll digging hyperkit Go bindings.
Good night💤
We used to have a hyperkit binding that included the C code, but there were lots of threading issues and other problems, hence we switched to calling the binary, even though it is less nice in some ways.
