Machine: La operación de creación con el controlador vmwarefusion no se completa

/ cc @frapposelli

esto es muy extraño, aparentemente su máquina se creó correctamente (ejecutó runScriptInGuest correctamente, lo que requiere que la máquina esté en fusión con las herramientas vmware funcionando correctamente) pero de alguna manera no pudo ingresar al proceso de aprovisionamiento.

@ehazlett ¿ son esos binarios creados a partir de master ?

Avíseme si necesita que ejecute algún tipo de ayuda / script de depuración. Feliz
ayudar.

El 13 de agosto de 2015 a las 07:26, Fabio Rapposelli [email protected]
escribió:

esto es _mu_ raro, aparentemente su máquina fue creada correctamente (
ejecutado runScriptInGuest correctamente, lo que requiere que la máquina esté activa
en fusión con las herramientas vmware ejecutándose correctamente) pero de alguna manera no pudo ingresar
el proceso de aprovisionamiento.

@ehazlett https://github.com/ehazlett son los binarios creados a partir de
Maestro ?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/machine/issues/1671#issuecomment -130605035.

Robin Bate Boerop

Veo el mismo comportamiento. runScriptInGuest y co. funciona bien, pero vmrun list no enumera la máquina virtual docker-machine.

Intentar ejecutar la máquina virtual manualmente a través de /Applications/VMware\ Fusion.app/Contents/Library/vmrun start ~/.docker/machine/machines/dev/dev.vmx da como resultado:

Error: Unknown error

No es tan útil, lo sé.

Puedo confirmar este problema en Docker 1.8.1, Machine 0.4.1 y Mac OS X 10.10.4.

@mikew , ¿puedes publicar el archivo vmware.log que está en ~/.docker/machine/machines/dev ? eso ayudaría a solucionar el problema.

Intentando ... ni siquiera puedo llegar a donde estaba fallando anteriormente
Aquí está el registro de esa carrera

Ignore el comentario anterior, estaba olvidando la bandera -D . Aquí hay otro intento con registros:

https://gist.github.com/mikew/9a20b864156f610923de#docker -output

https://gist.github.com/mikew/9a20b864156f610923de#vmware -fusion-logs

El mismo problema aqui. Mis datos en caso de que ayude ...

Detalles del sistema:

❯ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10.5
BuildVersion:   14F27

❯ docker -v
Docker version 1.8.1, build d12ea79

❯ docker-machine -v
docker-machine version 0.4.1 (e2c88d6)

❯ /Applications/VMware\ Fusion.app/Contents/Library/vmrun
vmrun version 1.14.2 build-2779224

Archivos de registro:

docker-machine -D create --driver vmwarefusion fusion

~ / .docker / machine / machines / fusion / vmware.log

Ok, esto es extraño, lo intenté mucho pero no puedo reproducir esto en absoluto, esta es la configuración de mi sistema:

~ ⟩ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10.5
BuildVersion:   14F27
~ ⟩ docker -v
Docker version 1.8.1, build d12ea79
~ ⟩ docker-machine -v
docker-machine version 0.5.0-dev (49cbc6b)
~ ⟩ "/Applications/VMware Fusion.app/Contents/Library/vmware-vmx" -v

VMware Fusion Information:
VMware Fusion 8.0.0 build-2985594 Release

y docker-machine simplemente funciona:

~ ⟩ docker-machine create -d vmwarefusion test-GH1671
Creating SSH key...
Creating VM...
Starting test-GH1671...
Waiting for VM to come online...
To see how to connect Docker to this machine, run: docker-machine env test-GH1671
~ ⟩ eval (docker-machine env test-GH1671)
~ ⟩ docker version
Client:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 19:47:52 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 02:49:29 UTC 2015
 OS/Arch:      linux/amd64
~ ⟩ docker run busybox date
Unable to find image 'busybox:latest' locally
latest: Pulling from library/busybox
cf2616975b4a: Pull complete
6ce2e90b0bc7: Pull complete
8c2e06607696: Already exists
library/busybox:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:38a203e1986cf79639cfb9b2e1d6e773de84002feea2d4eb006b52004ee8502d
Status: Downloaded newer image for busybox:latest
Thu Aug 27 15:53:17 UTC 2015

Les sugiero encarecidamente que abran un problema de soporte técnico sobre el problema [msg.vnet.padrConflict] que están encontrando, que probablemente sea el culpable de su problema con Fusion.

[msg.vnet.padrConflict] MAC address 00:0C:29:3E:BF:B2 of adapter Ethernet0 is within the reserved address range or is in use by another virtual adapter on your system. Adapter Ethernet0 may not have network connectivity.

Genial, lo investigaré. La máquina virtual creada por docker-machine no se inicia, e intentar iniciarla hace que Fusion comience a actuar de manera realmente extraña. Se queja de que ya se está ejecutando otra máquina virtual al intentar iniciar otra.

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10.5
BuildVersion:   14F27

$ docker -v
Docker version 1.8.1, build d12ea79

$ docker-machine -v
docker-machine version 0.4.1 (e2c88d6)

$ "/Applications/VMware Fusion.app/Contents/Library/vmware-vmx" -v

VMware Fusion Information:
VMware Fusion 8.0.0 build-2985594 Release

Sin suerte:

$ docker-machine create -d vmwarefusion test-GH1671
Creating SSH key...
Creating VM...
Starting test-GH1671...
Waiting for VM to come online...
Error creating machine: Maximum number of retries (60) exceeded
You will want to check the provider to make sure the machine and associated resources were properly removed.

Gracias @frapposelli , intenté actualizar a Fusion 8 ayer y también recibí el error de dirección MAC. Estudiará la posibilidad de abrir un ticket con VMware.

@frapposelli He actualizado el software en mi máquina y ahora coincide con las versiones que publicaste anteriormente. El problema persiste. En mi archivo vmware.log, veo la misma línea que mencionaste ("msg.vnet.padrConflict"). Abriría un problema con VMware, pero si hiciera eso, no podría explicar de dónde vino la dirección MAC elegida, cómo se eligió y por qué esperaba que funcionara. Simplemente tendría que referir VMware al código de la máquina acoplable. ¿Puede arrojar algo de luz sobre cómo Docker-Machine elige la dirección MAC?

@robinbb @ johnallen3d el docker-machine usa una plantilla vmx que está incrustada en el controlador (ver aquí ), esta plantilla contiene la directiva ethernet0.addressType = "generated" que obliga al hipervisor a generar automáticamente una nueva MAC en el primer arranque .

Para cualquiera que abra tickets para el soporte de VMware, siéntase libre de mencionar mi nombre directamente (para que puedan ingresarme internamente) y publique su número SR una vez que obtenga uno para que pueda rastrearlo.

Gracias de nuevo @frapposelli ,

Hice un poco de depuración y puedo confirmar que el "vmrun start" que se emite en Create () (https://github.com/docker/machine/blob/93366f22be4200bffb8b547a8a1f1052f3fb63e5/drivers/vmwarefusion/fusion_darwin.go#L207) no tener éxito. El vmware.log (~ / .docker / machine / machines / spinzo-vm / vmware.log) contiene las siguientes líneas interesantes:

2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: Msg_Post: Warning
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: [msg.vnet.padrConflict] MAC address 00:0C:29:87:83:87 of adapter 'Ethernet0' is within the reserved address range or is in use by another virtual adapter on your system. Adapter 'Ethernet0' may not have network connectivity.
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: ----------------------------------------
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: MsgIsAnswered: Using builtin default 'OK' as the answer for 'msg.vnet.padrConflict'
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VMXNET3 user: Ethernet0 Driver Info: version = 16974848 gosBits = 2 gosType = 1, gosVer = 0, gosMisc = 0
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:50.369-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:50.369-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)

Puedo confirmar que, con seguridad, no hay otras máquinas virtuales con exactamente esa dirección MAC en mi sistema.

¿Podría estar relacionado con el número 1434? Tuve este problema exacto con Fusion instalado a través de homebrew-cask , y una vez que lo instalé manualmente con el instalador de escritorio, las cosas parecían funcionar correctamente. (Si es así, espero que se pueda resolver, ya que preferiría no tener que instalar Fusion fuera de brewcask).

Estoy en VMWare Fusion 8.0, con MacOSX 10.10.5.

@mroth Podría ser, pero de hecho

No confié en brew para fusión o docker-machine. Instalé la máquina usando la caja de herramientas de Docker.

También utilicé el método de instalación proporcionado por VMware.

Reinstalé vmware y tengo 0 máquinas instaladas. Luego hice un machine-create y tuve el mismo error al ejecutar.

Sin embargo, logré abrir el archivo vmx con fusión e iniciarlo, me dio la opción de actualizarlo y lo hice. Comienza y se muestra como ejecutándose en docker-machine ls .

$ docker-machine ls
NAME    ACTIVE   DRIVER         STATE     URL                         SWARM
test2            vmwarefusion   Running   tcp://192.168.40.251:2376

Sin embargo, si trato de ssh, me da

$ docker-machine ssh test2
exit status 255

$ docker-machine ip test2
192.168.40.251

$ docker-machine url test2
tcp://192.168.40.251:2376

$ docker-machine env test2
open /Users/***/.docker/machine/machines/test2/ca.pem: no such file or directory

$ docker-machine regenerate-certs test2
Regenerate TLS machine certs?  Warning: this is irreversible. (y/n): y
Regenerating TLS certificates
Error getting SSH command: exit status 255

Tengo un error padrConflict en vmware.log. Sin embargo, si regenero la dirección mac en fusión, aparece un error al ejecutar docker-machine ls :

$ docker-machine ls
error getting URL for host test2: couldn't find MAC address in VMX file /Users/**/.docker/machine/machines/test2/test2.vmx
error getting URL for host test2: couldn't find MAC address in VMX file /Users/**/.docker/machine/machines/test2/test2.vmx
error determining if host is active for host test2: couldn't find MAC address in VMX file /Users/**/.docker/machine/machines/test2/test2.vmx

Ok, eliminemos ese intento fallido: docker-machine rm test2

Ahora intentemos crear con sudo:

$ sudo docker-machine create -d vmwarefusion test3 -D

Eso tiene éxito: /

A continuación, chown -R ese directorio de máquina con mi usuario local.

$ sudo chown -R *** test3

donde *** es mi usuario local

Ahora elimino los archivos / directorios lck y vmem . Abra el archivo vmx en Fusion e inícielo, nuevamente haciendo la actualización cuando me dé la opción. Puedo ejecutar docker-machine ls y verlo en ejecución:

 docker-machine ls
NAME    ACTIVE   DRIVER         STATE     URL                         SWARM
test3            vmwarefusion   Running   tcp://192.168.40.128:2376

Ahora puedo configurar mis variables env locales:

$ docker-machine env test3
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.40.128:2376"
export DOCKER_CERT_PATH="/Users/***/.docker/machine/machines/test3"
export DOCKER_MACHINE_NAME="test3"
# Run this command to configure your shell:
# eval "$(docker-machine env test3)"

$ eval "$(docker-machine env test3)"

Después de esto, ¡ docker-machine ssh funciona!

$ docker-machine ssh test3
                        ##         .
                  ## ## ##        ==
               ## ## ## ## ##    ===
           /"""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ /  ===- ~~~
           \______ o           __/
             \    \         __/
              \____\_______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
Boot2Docker version 1.8.1, build master : 7f12e95 - Thu Aug 13 03:24:56 UTC 2015
Docker version 1.8.1, build d12ea79

Espero que esto sirva como una solución temporal y arroje luz sobre el problema.

Entonces, basado en eso, estoy usando esto:

https://gist.github.com/mikew/66e15a8be8eaf7d6043c

Lo que hace que docker-machine ls muestre como en ejecución y activo, sin embargo, ssh todavía falla con exit status 255 aquí.

Ver la máquina virtual en ejecución en Fusion muestra [guestinfo] Failed to get vmstats. que no puede ser bueno.

@mikew se ve bien, pero no es necesario el pkill. Por alguna razón eso rompe las cosas. Aquí está el script actualizado:

#!/bin/bash

name="${1:-test}"
dir="${HOME}/.docker/machine/machines/${name}"
vmx="${dir}/${name}.vmx"

echo "Running docker-machine create, will need sudo for vmwarefusion"
sudo docker-machine -D create -d vmwarefusion "${name}"

echo "Changing owner of ${dir} to ${USER}"
sudo chown -R "${USER}" "${dir}"

echo "Cleaning vmem/lck files"
rm -r \
  "${dir}"/*.vmem \
  "${dir}"/*.lck

echo "Opening in Fusion to upgrade"
open "${vmx}"

echo "You should be able to run 'eval \"\$(docker-machine env ${name})\"'"

FYI: esto funcionó para mí después de actualizar VMware Fusion a v8. ¡Gracias por la resolución de problemas de @geek y el script @mikew!

Bueno, parecería que la máquina que se crea con el script anterior ya no es accesible si suspendo la interfaz gráfica de usuario de Fusion o realizo un docker-machine stop/start . De todos modos, esa ha sido mi experiencia reciente.

lo mismo aquí, lamentablemente

• Mike Wyatt

El lunes 31 de agosto de 2015 a las 11:44 p.m., John Allen [email protected]
escribió:

Bueno, parece que la máquina que se crea con lo anterior
El script ya no es accesible si suspendo la interfaz gráfica de usuario de Fusion o realizo una
detener / iniciar. De todos modos, esa ha sido mi experiencia reciente.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/docker/machine/issues/1671#issuecomment -136557908.

@frapposelli, ¿ ha tenido suerte al rastrear el problema? Noté en los pasos de reproducción que está probando con master en lugar de la versión de lanzamiento de docker-machine, ¿ha intentado nuevamente con la última versión de lanzamiento?

Actualicé el script, mientras que pkill empeoró las cosas, hacer vmrun stop significa que no tienes que eliminar los archivos de bloqueo ni nada.

Después de que la VM se apague limpiamente, simplemente cambie los permisos y todo funcionará como se esperaba. Solo necesita sudo para los primeros comandos.

https://gist.github.com/mikew/66e15a8be8eaf7d6043c

Gracias por la actualización @mikew , planeo probarla pronto. Sin embargo, una pregunta, ¿es necesario el comando upgradevm ? Noto que lo tienes comentado en la esencia.

No, realmente no. Simplemente elimina el mensaje si alguna vez desea ejecutar la máquina virtual en Fusion.

@mikew gracias por el script actualizado :)

Después de ejecutar el script, ¿puede ejecutar docker-machine start y funciona, o hay otros pasos manuales que debe seguir después de ejecutar el script?

Pude hacer todo, repetidamente, sin necesidad de sudo después de la configuración inicial.

El único problema que surgió fue al hacer el "inicio de la máquina acoplable" cuando se suspendió la VM, ssh tuvo errores después de eso. Pero después de detener e iniciar la VM a través de la máquina acoplable, todo funcionó a la perfección.

El guión de la esencia de

@robinbb Si se siente cómodo usando sudo docker-machine ... todo momento, no necesita el script en absoluto.

Es extraño que todavía necesites sudo. ¿Tiene una copia de Fusion instalada en /Applications ?

@mikew El 'sudo' es necesario porque, sin él, docker-machine tiene el comportamiento para el que abrí originalmente este problema y, para ser claros, la VM no se iniciará con un "docker-machine start xyz" después de crear falla.

El script no es necesario, pero es una forma conveniente de recordar cambiar los permisos de ~ / .docker / machine / machines / xyz. De lo contrario, incluso emitir "Docker" da como resultado una falla en los permisos.

@frapposelli ¿El hecho de que mi umask esté configurado en 0077 causaría problemas de permisos que se superan al emitir docker-machine como root?

@frapposelli alguna actualización?

@vmware ^^^?

@geek nada todavía, te lo haré saber tan pronto como reciba un mensaje de soporte.

Intenté reproducirme de nuevo el otro día, pero no pude.

Mi problema desapareció después de actualizar a El Capitan GM Candidate (15A282b)

Tuve este problema en El Capitan GM Candidate, después de actualizar de VMware Fusion 6 a 8, y luego instalar docker-machine.

Reiniciar resolvió el problema por mí.

Estoy bastante seguro de que se trata de algún tipo de corrupción de instalación / problema de permisos / problema de configuración con Fusion.

Para las personas que aún enfrentan este problema, ¿pueden intentar eliminar Fusion por completo (siga este KB http://kb.vmware.com/kb/1017838) y reinstalar? que debería eliminar cualquier condición existente.

@frapposelli Probé la reinstalación, sin suerte :(

@frapposelli He desinstalado VMware Fusion completamente de acuerdo con las instrucciones citadas y reinstalé Fusion 8. El problema persiste, con los mismos síntomas.

El vmware.log asociado está aquí: https://dl.dropboxusercontent.com/u/31368575/vmware.log , sin más mensaje "padrConflict".

Puedo solucionar el problema emitiendo comandos 'docker-machine' con 'sudo'.

Probé esto hace unas semanas, lo intenté de nuevo hoy. Parece que no puedo crear una máquina acoplable con fusión para crear y comenzar, incluso después de actualizar varias cosas / reinstalar.

Nombre del producto: Mac OS X
ProductoVersión: 10.10.5
BuildVersion: 14F27
Docker versión 1.8.2, compilación 0a8c2e3
docker-machine versión 0.4.1 (HEAD)
vmrun versión 1.15.0 build-3094680

Probé la instalación de Homebrew y la descarga de VMWare Fusion .dmg de estilo antiguo.

Al encontrarme con esto también, el script de @mikew y

Recibiendo este error a pesar de que hay un ethernet0.address en dev.vmx .

Not there yet 1/60, error: couldn't find MAC address in VMX file /Users/msch/.docker/machine/machines/dev/dev.vmx

Todavía me falla con docker 1.9 y vmware fusion 8.0.2

Recibo el mismo error que @MSch

- (~) $ -> sw_vers && docker -v && docker-machine -v && "/ Applications / VMware Fusion.app/Contents/Library/vmware-vmx" -v
Nombre del producto: Mac OS X
ProductoVersión: 10.11.1
BuildVersion: 15B42
Docker versión 1.9.0, compilación 76d6bc9
docker-machine versión 0.5.0 (HEAD)

Información de VMware Fusion:
Versión de VMware Fusion 8.0.2 build-3164312

Para todas las personas que todavía tienen el problema, ¿pueden presentar una solicitud de servicio con el soporte de VMware y publicar el número SR para que pueda rastrear? Quiero aclarar esto, pero hasta ahora no pude reproducirlo en absoluto.

@frapposelli tiene un enlace y ¿alguien a quien debemos etiquetar en el problema?

@geek use este enlace como punto de partida: https://www.vmware.com/support/file-sr/ y no dude en mencionarme directamente en el SR.

@frapposelli, ¿ puede ayudarme a dirigirme a un número de soporte para llamar? Parece que no puedo llegar a ninguna parte del sitio.

En este punto solo quiero un reembolso. No soy fanático de Oracle, así que elegí VMWare para evitar usar virtualbox. VMWare anunció que funciona con Docker. El sitio de Docker incluso hace esta afirmación y se vincula a su controlador @frapposelli. Definitivamente no está funcionando como se anuncia y en este punto se ha roto durante meses.

Aprecio que intentes ayudar, @frapposelli.

Los números de https://www.vmware.com/support/file-sr/file-sr-phone.html :

EE. UU. Y Canadá: 1-877-4-VMWARE (1-877-486-9273) o 1-650-475-5345.

para números internacionales: https://www.vmware.com/support/contacts/us_support.html

Creé un SR según lo solicitado: 15802564411.

Bien, ahora que lo he abierto lo descubrí (al menos en mi caso). Soy un usuario de boxen y originalmente había instalado vmware fusion 7 usando boxen (lo que significa usar homebrew / cask). Cuando se configuró, enlazó simbólicamente los archivos de la aplicación fusion7 en mi directorio bin homebrew. Cuando actualicé a 8, eso no se eliminó, por lo que docker-machine todavía lo usaba para llamar a vmrun. Y descubrí que el barril tampoco podía eliminarlo por los medios normales. De alguna manera pensó que ya no estaba instalado, pero aún estaba allí.

Para solucionar esto, seguí estos pasos:

• sudo rm -rf / opt / homebrew-cask / Caskroom / vmware-fusion
• sudo rm -f / opt / boxen / homebrew / bin / vm * (Marque este, coincidió con todos los que quería eliminar)
• sudo rm -rf /Users/myusername/.docker /var/root/.docker (solo para estar seguro)

Luego eliminé la aplicación Fusion de la carpeta Aplicación y la instalé desde el dmg que había descargado para realizar la actualización. Después de esto, cuando ejecuté docker-machine, todo funcionó limpio de principio a fin sin problemas.

Esto es lo que tuve que hacer para que esto funcionara:

• Eliminar completamente VMWare Fusion
• Eliminar completamente la ventana acoplable y la máquina acoplable
• Instale VMWare Fusion usando el .dmg de VMWare. _¡No_ use barrica de cerveza para esto!
• brew barril instalar docker docker-machine

Hay algún problema con los permisos en vmrun. Si instalo Fusion usando brew-cask, vmrun no tiene los permisos correctos, y hacer que sea setuid root aún no funciona. Sin embargo, la instalación desde el .dmg se realiza correctamente.

También parece que el controlador está buscando vmrun cuando se instala y nunca actualiza la ruta, incluso si elimina Fusion a través de brew cask y lo instala a través de .dmg.

También había tenido problemas como este y, como sugirió @robinbb , en mi caso, estaba siendo causado por una umask 077. Cambiar mi umask a 022 lo resolvió. Creé un PR para que el controlador hiciera esto por sí mismo, y me ha funcionado bien durante algunas semanas.

Curiosamente, noté esta mañana que la versión estándar 0.5.1 de docker-machine parece estar funcionando bien en El Capitan (que actualicé a ayer), por lo que esto puede ser un problema menor en El Capitan. Sin embargo, todavía no estoy completamente convencido.

Acabo de encontrar el mismo problema con docker-toolbox 1.12-rc3, vmware fusion 8.1.
Los scripts anteriores no funcionaron, pero reiniciar mi computadora portátil sí.

Con VMWare Fusion versión 8.1.1 (3771013), macOS Sierra 10.12 y Docker versión 8.1.1 (3771013), este problema ya no me ocurre. Clausura.