Thanks for this piece of software, it helped us a lot. I'm chasing an intermittent situation that might originate in this driver.
THE ENVIRONMENT
windows 7 x64, docker is installed and configured using this driver, our machine is called "default" and everything works, running 4 containers inside, using VMware Workstation 10 with default DHCP settings, manually configured some port forwarding rules
there is a startup batch file that calls the start.sh (.sh code copied from the vmwareworkstation driver readme): bash.exe --login -i start.sh docker login -u xx -p xx; docker-compose -f ~/xx/docker-compose.yml up -d
THE PROBLEM
sometimes after a system restart the start.sh gets stuck on docker-machine commands - last one "waiting for SSH"... it took quite some time to notice what's going on - docker cannot SSH to the machine, because VMnet8 network adapter has wrong IP address (169.254.x.x). Addresses from this range are used by Windows in case of network issues e.g. IP address conflict.
digging deeper, the VMware's DHCP table entries show that tere are 2 devices having the same mac address and IP, but different host name: one is called "default" and the other is called "boot2docker"
THE QUESTIONS
Now how did that happen? The start.sh uses $VM variable for setting the machine name. The variable is populated on this line: VM=${DOCKER_MACHINE_NAME-default}, meaning it's either the existing machine name from $DOCKER_MACHINE_NAME or "default".
There are 2 theories:
there is a bug in the stack somewhere that would fill the docker machine name variable with "boot2docker" string - either docker-machine or this driver or the .sh script
the name of the virtual machine is "boot2docker" initially and it gets replaced only later by some script, meaning our issues are based on random timing of the 2 events (setting the name and getting the address from DHCP)
Given the date of this and that it was on Windows 7, ill close this issue. Sorry for not replying before. If you see this issue again, please open a new one.
Thanks for this piece of software, it helped us a lot. I'm chasing an intermittent situation that might originate in this driver.
THE ENVIRONMENT
THE PROBLEM
THE QUESTIONS Now how did that happen? The start.sh uses $VM variable for setting the machine name. The variable is populated on this line: VM=${DOCKER_MACHINE_NAME-default}, meaning it's either the existing machine name from $DOCKER_MACHINE_NAME or "default".
There are 2 theories:
Any ideas??