Description of problem:
Running che.sh does not start the che server.
Che version: 4.0.0-RC11
Che install directory: /Users/rrpolanco
Docker version: Docker version 1.8.1
Java version: 1.8
Environment details (AWS, VirtualBox, physical, etc.): virtualbox
How reproducible:
I have the following docker-machine (via docker-machine ls):
NAME ACTIVE DRIVER STATE URL SWARM
dev virtualbox Stopped
When I run che.sh, I get the following output:
Could not find an existing docker machine.
Creating docker machine named default... Please be patient, this takes a couple minutes the first time.
Successfully started docker machine named default...
The che script doesn't seem to create a docker-machine named _default_ nor does it run the server.
Am I missing something?
@rrpolanco Very interesting. It looks like your virtualbox was not installed properly. I am assuming that this is a Mac server?
A few things:
docker-machine rm default. docker-machine create --driver virtualbox default. What would the output of this be? It should give you some indication of whether virtualbox is installed properly on your computer.@TylerJewell Yes, I'm running the Che server on a Mac. Virtualbox is installed properly as I'm able to bring up my other docker machines just fine. Interestingly, if I create a docker machine named _default_ and then start the che server, it works.
Huh... all we are doing in the che.sh script is calling the docker-machine create command. One thing you could try is to change the name of the vbox machine. che --machine:<name> run and then let me know the output. Try to create a machine other than default to see how it goes.
I created a docker-machine titled _dev_.
Executed bin/che.sh --machine:dev run and che.sh started the _dev_ machine and the server started successfully.
Huh. Vbox has its quirks for sure. We are excited by the native docker for Mac coming soon. No more vbox setup required.
So is this a bug in the che.sh? It can be reproduced fairly easy: execute che.sh run when there isn't an existing 'default' docker-machine.
It is unclear that it is a bug in the script. We haven't had any other reports of other Mac users having the same problem. And about 15000 Mac installs so far.
My suspicion is that you previously had a machine named default and you ran into a conflict. Maybe a sokution would be to have our machine name itself Che-machine instead of default to avoid conflicts.
It is unlikely a bug in the script since many of Che engineers use Macs. Maybe reinstalling Virtual Box will help?
@TylerJewell How soon after the release for "Docker for Windows" will che be able to work with it. I assume it's modifying the che.sh file for Windows. Will this help with the accessing che remotely or will network configuration still be required?
Of course, we have signed up for beta and will play with it as soon as it's out. However, as long as there's an additional virtualization layer, networking issue may occur. Of course, if you run and access Che locally, there are no issues.
@james10174 I am playing with the Docker for Windows Beta now. It's gorgeous.
The improvements necessary to the che.sh script will not be that much. Essentially, if it's installed, then we remove our dependency on Virtual Box or docker-machine, which ultimately guts about 33% of the script out. Essentially, we can treat all systems like Linux (remove all the OS checks, not have to do verifications on virtual box setup, etc.)
The new product requires hyperv under the covers though. And Hyperv is not universally provided on all Windows systems. It's not on Windows Home, for example. So we may not be able to discontinue support for docker machine.
@TylerJewell This is great. I think I may just give up on trying to get the remote setup working. I think most of the problem comes from virtualbox networking. I have used linux in the past(did linux from scratch before) but I really don't want to change my computers at home to it(gaming). Are there any cost effective linux computers with soc or other embedded devices that perform really well with che and docker. I have a RPI2 but don't think it or RPI3 would be fast enough. I am looking for something like RPI that may cost more but compile quickly and has open source GPU drivers. AMD open source driver news is a little over my head at this point on how I could benefit from it but I really like it's direction to open source. I will be using che on a robot for testing. Power usage not a huge issue during testing but would like i2c and smaller form factor.
@kartben just got Eclipse Che running on a Raspberry Pi. I am quite excited to see the demo of that. And we are also working on some open source components to build IOT projects for Samsung Artik boards.
As for which is the best Linux system to run Codenvy on, I am not really qualified to provide any guidance here. But I know that @kartben has a lot of in depth IOT experience.
We have found that Che runs screaming fast on most Linux systems. So it really comes down to getting the CPU & RAM that will make you happiest for performance.
@TylerJewell new Docker Beta in Win will require code changes - it's about the way we guess all the networking details. It's different in a new Docker. But yes, it looks and feels like a native Docker :)
@eivantsov So if I run che directly in the new Docker it should make things even easier to setup right? I have requested the beta version of docker and plan to play with it if and when I get authorized. I would just need to expose/forward ports required in windows. I will be working on this solution once/if I get beta.

I'll experiment with beta Docker on Windows as well.
This pull request should fix the issue - https://github.com/eclipse/che/pull/972
Closing the issue. Feel free to reopen if the problem is still there.
Most helpful comment
Huh. Vbox has its quirks for sure. We are excited by the native docker for Mac coming soon. No more vbox setup required.