Hacker News Reader

Comment by falcolas | Hacker News Reader

The last time I used xhyve, it kernel panic'ed my mac. Researching this on the xhyve github account [1] showed that it was determined that it's due to a bug with Virtualbox. That is, if you've started a virtual machine since your last reboot with Virtualbox, subsequent starts of xhyve panic.

So, buyer beware, especially if said buyer also uses tools like Vagrant.

[1] https://github.com/mist64/xhyve/issues/5

I've said before that I think the Docker devs have been iterating too fast, favoring features over stability. This development doesn't ease my mind on that point.

EDIT: I'd appreciate feedback on downvotes. Has the issue been addressed, but not reflected in the tickets? Has Docker made changes to xhyve to address the kernel panics?

View on HN

Thanks, this is useful feedback. There are various workarounds in the app to prevent such things, but the purpose of the beta program is to ensure that we catch all the weird permutations that happen when using hardware virt (e.g. the Android emulator).

If anyone sees any host panics ever, we'd like to know about it (beta-feedback@docker.com) and fix it in Docker for Mac and Windows. Fixes range from hypervisor patches to simply doing launch-time detection of CPU state and refusing to run if a dangerous system condition exists.

It's good to see that you folks are taking ownership of such a critical portion of this infrastructure. I hope you understand why people can get worried when Docker has a history of integrating with third party software, and responding "Not Our Problem" when problems arise.

Who downvoted this? This is a real experience report, expressing valid concerns, citing an issue tracker for more information.

Is this type of comment discouraged on HN? If so, why?

I didn't downvote, but I'd imagine people don't agree with his criticism of stability because it conflicts with VirtualBox. VirtualBox has to invasively modify your system configuration in order to accomplish virtualization. On the other hand, xhyve is using an OS X sanctioned virtualization technique (hypervisor.framework) that works within sandboxed apps. This is the route going forward that Apple advocates for virtualization, not the method that VirtualBox uses.

> people don't agree with his criticism of stability because it conflicts with VirtualBox

Folks are welcome to disagree, but Docker has a history of shipping software which uses a 3rd party feature which breaks, to which they frequently responded "not our code, talk to someone else": btrfs instability, corrupted volumes due to conflicting devmapper libraries, iptables dropping routes, upgrades orphaning containers, etc.

I realize they don't have control over all of the variables, but constantly releasing unstable 3rd party features was not the greatest behavior, and the "Not My Problem" response to issues is aggravating.

All that said, since they're working against their own fork of xhyve, it is a sign that these kinds of issues will be addressed by the Docker team this time, which is a good thing.

This is exactly correct. We're really enjoying working with the Hypervisor.framework, VMnet.framework, and all the various hooks Apple has exposed for apps like Docker for Mac. There are some bugs in the short-term, but Apple has been steadily addressing our Radar bugs and we have workarounds in place in the Application for the most annoying ones.

I don't think that makes it makes his question any less valid. Yosemite has been out 18 months, true, but hypervisor.framework has had a lot of work done - even Docker acknowledges that they've been filing several Radar bugs on it even to this day.

Yes, any new virtualization projects should strongly consider using it, but that doesn't mean any issues with projects with have a massive investment in tooling and ecosystem should be considered deprecated and dead just because of this.

I'd bet it has to do with criticizing the Docker developers for a bug which is actually in one of two independent projects, and doing so in reaction to an announcement of something explicitly billed as a way to avoid that problem.

I doubt it would be getting downvotes if the comment was just a statement of fact without the somewhat random slam against the Docker developers.

Yes, I think this issue has been addressed for a while – it was solved in a release of Virtualbox. I'm sure that 5.0+ doesn't have the conflict with xhyve.

vbox4 caused issues with xhyve when xhyve first came out (not sure if it's still an issue), vbox5 coexists just fine.

I've had similar experiences as well as times where xhyve made it so my laptop could not come out of sleep.

xhyve is wonderful but still needs some work and it seems like the main dev isn't interested in continuing work on it at this point[1]. Hopefully Docker's usage will spur more work on xhyve.

[1] Last commit on xhyve is December 28th, 2015 https://github.com/mist64/xhyve/commits/master

We've had to fork xhyve very heavily for Docker to embed it, and are making many changes in a very rapid loop as we improve d4mac. We're still debating whether to contribute back into xhyve or just make it a separate open-source project with its own pace and design tradeoffs. Either way we are impatient to open-source it.

I'd hope some of your improvements make it back to xhyve

What's a little mind-boggling to me (I have some, not the best, but some experience with the Docker devs) is that the mantra for a long time has been "We're not going to add features to Docker if that feature could wrap Docker instead."

Makes sense, that's fine. But, it seems they've gone (and continue) to do that very thing!

I can easily get kernel panic from my Mac using the docker-machine with VirtualBox driver. It just happens so easy if you're not on latest VirtualBox or even possibly on the latest version. It happens almost half of the time to me.

I think this was related with a kernel bug which was fixed with the latest release from OSX (released yesterday).

I personally discovered this bug while using dlite, which uses xhyve behind the scenes.

I too am seeing it as fixed now.

Updating to a newer version of VirtualBox solved that issue.

Reply on news.ycombinator.com