Machine: A operação de criação com o driver vmwarefusion não foi concluída

/ cc @frapposelli

isso é muito estranho, aparentemente sua máquina foi criada corretamente (ela executou runScriptInGuest corretamente, o que requer que a máquina esteja em fusão com as ferramentas VMware funcionando corretamente), mas de alguma forma falhou ao entrar no processo de provisionamento.

@ehazlett são aqueles binários criados a partir de master ?

Deixe-me saber se você precisa que eu execute algum tipo de ajuda / script de depuração. Feliz
ajudar.

Em 13 de agosto de 2015 às 07h26, Fabio Rapposelli [email protected]
escrevi:

isso é _muito_ estranho, aparentemente sua máquina foi criada corretamente (
executado runScriptInGuest corretamente, o que requer que a máquina esteja ativa
em fusão com as ferramentas VMware funcionando corretamente), mas de alguma forma não conseguiu entrar
o processo de provisionamento.

@ehazlett https://github.com/ehazlett são aqueles binários criados a partir de
mestre ?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/machine/issues/1671#issuecomment -130605035.

Robin Bate Boerop

Estou vendo o mesmo comportamento. runScriptInGuest e co. funciona bem, mas vmrun list não lista a VM docker-machine.

Tentar executar a VM manualmente por meio de /Applications/VMware\ Fusion.app/Contents/Library/vmrun start ~/.docker/machine/machines/dev/dev.vmx resulta em:

Error: Unknown error

Não é tão útil, eu sei.

Posso confirmar esse problema no Docker 1.8.1, Machine 0.4.1 e Mac OS X 10.10.4.

@mikew, você pode postar o arquivo vmware.log que está em ~/.docker/machine/machines/dev ? isso ajudaria a solucionar o problema.

Tentando ... não consigo nem chegar onde estava falhando anteriormente
Aqui está o registro dessa corrida

Ignore o comentário anterior, eu estava esquecendo a bandeira -D . Aqui está outra tentativa com registros:

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

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

Mesmo problema aqui. Meus detalhes caso ajude ...

Detalhes do 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

Arquivos de log:

docker-machine -D create --driver vmwarefusion fusion

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

Ok, isso é estranho, eu tentei bastante, mas não consigo reproduzir isso, esta é a configuração do meu 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

e docker-machine simplesmente 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

Eu sugiro fortemente que vocês abram um problema de suporte técnico sobre o [msg.vnet.padrConflict] problema que você está encontrando, que provavelmente é o culpado do seu problema com o 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.

Legal, vou dar uma olhada nisso. A VM criada por docker-machine falha ao iniciar e tentar iniciá-la faz o Fusion começar a agir de maneira muito estranha. Ele reclama que outra máquina virtual já está em execução ao tentar iniciar outra.

$ 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

Sem sorte:

$ 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.

Obrigado @frapposelli , tentei atualizar para o Fusion 8 ontem e recebi um erro de endereço MAC com isso também. Analisará a abertura de um tíquete com VMware.

@frapposelli Eu atualizei o software em minha máquina e agora ele corresponde às versões que você postou acima. O problema persiste. No meu arquivo vmware.log, vejo a mesma linha que você mencionou ("msg.vnet.padrConflict"). Eu abriria um problema com o VMware, mas se fizesse isso, não seria capaz de explicar de onde veio o endereço MAC escolhido, como foi escolhido e por que esperava que funcionasse. Eu simplesmente teria que referir o VMware ao código da máquina docker. Você pode esclarecer como a docker-machine escolhe o endereço MAC?

@robinbb @ johnallen3d o docker-machine usa um modelo vmx que está embutido no driver (veja aqui ), este modelo contém a diretiva ethernet0.addressType = "generated" que força o hipervisor a gerar automaticamente um novo MAC na primeira inicialização .

Para qualquer pessoa que esteja abrindo tíquetes para o suporte da VMware, sinta-se à vontade para mencionar meu nome diretamente (para que eles possam me conectar internamente) e poste seu número SR assim que conseguir um para que eu possa rastreá-los.

Obrigado novamente @frapposelli , enviei um tíquete e recebi SR # 15745066808. Esperando que possamos resolver isso. Já faz algum tempo que estou ansioso para executar o docker no Fusion!

Fiz algumas depurações e posso confirmar que o "vmrun start" emitido em Create () (https://github.com/docker/machine/blob/93366f22be4200bffb8b547a8a1f1052f3fb63e5/drivers/vmwarefusion/fusion_darwin.go#L207) não ter sucesso. O vmware.log (~ / .docker / machine / machines / spinzo-vm / vmware.log) contém as seguintes linhas interessantes:

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)

Posso confirmar que, com certeza, não existem outras VMs com exatamente esse endereço MAC no meu sistema.

Isso pode estar relacionado a # 1434? Tive exatamente esse problema com o Fusion instalado via homebrew-cask e, depois que instalei manualmente com o instalador da área de trabalho, as coisas pareceram funcionar corretamente. (Se for assim, espero que possa ser resolvido, já que eu preferiria fortemente não ter que instalar o Fusion fora da brewcask.)

Estou no VMWare Fusion 8.0, com MacOSX 10.10.5.

@mroth Pode ser, mas eu realmente

Eu não confiei na mistura para fusão ou máquina docker. Instalei a máquina usando a caixa de ferramentas do docker.

Também usei o método de instalação fornecido pela VMware.

Reinstalei o vmware e tenho 0 máquinas instaladas. Em seguida, fiz um machine-create e tive o mesmo erro na execução.

No entanto, consegui abrir o arquivo vmx com o fusion e iniciá-lo, ele me deu a opção de atualizá-lo e o fiz. Ele começa e mostra como rodando em docker-machine ls .

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

No entanto, se eu tentar ssh, isso me dá

$ 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

Eu tenho um erro padrConflict no vmware.log. No entanto, se eu regenerar o endereço mac no Fusion, recebo um erro ao executar 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, vamos remover essa tentativa quebrada: docker-machine rm test2

Agora vamos tentar criar com sudo:

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

Isso é bem-sucedido: /

Em seguida, eu chown -R esse diretório de máquina com meu usuário local.

$ sudo chown -R *** test3

onde *** é meu usuário local

Eu agora removo os lck e vmem arquivos / diretórios. Abra o arquivo vmx no Fusion e inicie-o, novamente fazendo a atualização quando me der a opção. Posso executar docker-machine ls e vê-lo em execução:

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

Agora posso definir minhas variáveis ​​env locais:

$ 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)"

Depois disso, 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 isso ajude a servir como uma solução temporária e esclareça o problema.

Com base nisso, estou usando:

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

O que faz docker-machine ls exibi-lo como em execução e ativo, entretanto o ssh ainda falha com exit status 255 aqui.

Visualizar a VM em execução no Fusion mostra [guestinfo] Failed to get vmstats. que não pode ser bom.

@mikew parece bom, mas não há necessidade do pacote. Por algum motivo, isso quebra as coisas. Aqui está o script atualizado:

#!/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 - isso funcionou para mim depois de atualizar o VMware Fusion para v8. Obrigado pela solução de problemas do @geek e do script @mikew!

Bem, parece que a máquina que é criada com o script acima não está mais acessível se eu suspender a interface do Fusion ou executar um docker-machine stop/start . Essa tem sido minha experiência recente de qualquer maneira.

mesmo aqui, infelizmente

• Mike Wyatt

Na segunda-feira, 31 de agosto de 2015 às 23h44, John Allen [email protected]
escrevi:

Bem, parece que a máquina criada com o acima
o script não estará mais acessível se eu suspender o Fusion gui ou executar uma docker-machine
parar / iniciar. Essa tem sido minha experiência recente de qualquer maneira.

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/docker/machine/issues/1671#issuecomment -136557908.

@frapposelli , você teve alguma sorte em rastrear o problema? Percebi nas etapas de reprodução que você está tentando com o master em vez da versão de lançamento do docker-machine. Você tentou novamente com a versão de lançamento mais recente?

Eu atualizei o script, enquanto pkill piorou as coisas, fazer vmrun stop significa que você não tem que remover os arquivos de bloqueio nem nada.

Depois que a VM for desligada de forma limpa, basta alterar as permissões e as coisas funcionam conforme o esperado. Você só precisa do sudo para os primeiros comandos.

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

Obrigado pela atualização @mikew , pretendo fazer uma tentativa em breve. Uma pergunta, porém, é o comando upgradevm necessário? Percebo que você o comentou na essência.

Não, realmente não. Apenas remove o prompt se você quiser executar a VM no próprio Fusion.

@mikew, obrigado pelo script atualizado :)

Depois de executar o script, você consegue executar docker-machine start e funciona ou há outras etapas manuais que você executa após executar o script?

Consegui fazer tudo, repetidamente, sem precisar de sudo após a configuração inicial.

O único problema que surgiu foi ao fazer "docker-machine start" quando a VM estava suspensa, o ssh apresentou erros depois disso. Mas depois de parar e iniciar a VM via docker-machine, tudo funcionou perfeitamente.

O script da essência de

@robinbb Se você se sente confortável em usar sudo docker-machine ... , você não precisa do script.

É estranho que você ainda precise do sudo. Você tem uma cópia do Fusion instalada em /Applications ?

@mikew O 'sudo' é necessário porque, sem ele, docker-machine tem o comportamento para o qual eu originalmente abri este problema - e, para ser claro, a VM não iniciará com um "docker-machine start xyz" após a criação falha.

O script não é necessário, mas é uma maneira conveniente de lembrar de alterar as permissões de ~ / .docker / machine / machines / xyz. Caso contrário, mesmo a emissão de "docker" resultará em uma falha de permissão.

@frapposelli O fato de meu umask ser definido como 0077 causaria problemas de permissões que são superados emitindo docker-machine como root?

@frapposelli alguma atualização?

@vmware ^^^?

@geek nada ainda, resposta do suporte.

Tentei reproduzir novamente outro dia, mas não conseguiu.

Meu problema desapareceu após a atualização para El Capitan GM Candidate (15A282b)

Tive esse problema no El Capitan GM Candidate, após atualizar do VMware Fusion 6 para 8 e instalar a docker-machine.

A reinicialização resolveu o problema para mim.

Tenho certeza que é algum tipo de problema de corrupção / permissão / configuração de instalação com Fusion.

Para as pessoas que ainda enfrentam esse problema, você pode tentar remover o Fusion completamente (siga este KB http://kb.vmware.com/kb/1017838) e reinstalar? isso deve limpar qualquer condição existente.

@frapposelli Eu

@frapposelli Desinstalei o VMware Fusion inteiramente de acordo com as instruções citadas e reinstalei o Fusion 8. O problema permanece, com os mesmos sintomas.

O vmware.log associado está aqui: https://dl.dropboxusercontent.com/u/31368575/vmware.log , sem mais mensagens "padrConflict".

Posso contornar o problema emitindo comandos 'docker-machine' com 'sudo'.

Tentei isso algumas semanas atrás, tentei novamente hoje. Não consigo obter uma docker-machine com fusão para criar e iniciar, mesmo depois de atualizar várias coisas / reinstalar.

Nome do produto: Mac OS X
Versão do produto: 10.10.5
BuildVersion: 14F27
Docker versão 1.8.2, compilação 0a8c2e3
docker-machine versão 0.4.1 (HEAD)
vmrun versão 1.15.0 build-3094680

Experimentei a instalação do homebrew e o download do VMWare Fusion .dmg no estilo antigo.

Encontrando isso também, os @mikew e

Obtendo este erro mesmo que haja ethernet0.address em dev.vmx .

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

Ainda falhando para mim com docker 1.9 e vmware fusion 8.0.2

Estou recebendo o mesmo erro que @MSch

- (~) $ -> sw_vers && docker -v && docker-machine -v && "/ Applications / VMware Fusion.app/Contents/Library/vmware-vmx" -v
Nome do produto: Mac OS X
Versão do produto: 10.11.1
BuildVersion: 15B42
Docker versão 1.9.0, compilação 76d6bc9
docker-machine versão 0.5.0 (HEAD)

Informações do VMware Fusion:
Versão do VMware Fusion 8.0.2 build-3164312

Para todas as pessoas que ainda estão tendo o problema, você pode registrar uma solicitação de serviço com o suporte da VMware e postar o número SR para que eu possa rastrear? Eu quero definir isso, mas até agora não fui capaz de reproduzi-lo.

@frapposelli tem um link e alguém que precisamos marcar no problema?

@geek use este link como ponto de partida: https://www.vmware.com/support/file-sr/ e sinta-se à vontade para me mencionar diretamente no SR.

@frapposelli você pode ajudar a direcionar-me para um número de suporte para ligar, não consigo chegar a lugar nenhum no site.

Neste ponto, quero apenas um reembolso. Não sou fã do Oracle, então optei pelo VMWare para evitar o uso do virtualbox. VMWare anunciou que funciona com docker. O site docker ainda faz essa afirmação e vincula ao seu driver @frapposelli. Definitivamente não está funcionando como anunciado e neste ponto está quebrado há meses.

Agradeço por ter tentado ajudar, @frapposelli.

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

EUA e Canadá: 1-877-4-VMWARE (1-877-486-9273) ou 1-650-475-5345.

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

Criei um SR conforme solicitado: 15802564411.

Ok, agora que abri, descobri (pelo menos no meu caso). Eu sou um usuário boxen e tinha instalado originalmente o vmware fusion 7 usando boxen (que significa usar homebrew / barril). Quando isso foi configurado, ele vinculou simbolicamente os arquivos do aplicativo fusion7 ao diretório bin do meu homebrew. Quando eu atualizei para 8, isso não foi excluído, então docker-machine ainda estava usando isso para chamar o vmrun. E descobri que o barril também não foi capaz de removê-lo pelos meios normais. De alguma forma, ele pensou que não estava mais instalado, mas ainda estava lá.

Para corrigir isso, segui estas etapas:

• sudo rm -rf / opt / homebrew-cask / Caskroom / vmware-fusion
• sudo rm -f / opt / boxen / homebrew / bin / vm * (marque este, ele corresponde a todos os que eu queria excluir)
• sudo rm -rf /Users/myusername/.docker /var/root/.docker (só para ter certeza)

Em seguida, destruí o aplicativo Fusion da pasta de aplicativos e instalei o dmg que baixei para fazer a atualização. Depois disso, quando executei docker-machine, tudo funcionou limpo do início ao fim, sem problemas.

Aqui está o que eu tive que fazer para fazer isso funcionar:

• Remova completamente o VMWare Fusion
• Remova completamente o docker e a docker-machine
• Instale o VMWare Fusion usando o .dmg do VMWare. _Não_ use barril de cerveja para isso!
• brew cask install docker docker-machine

Há algum problema com as permissões no vmrun. Se eu instalar o Fusion usando o brew-cask, o vmrun não terá as permissões corretas e torná-lo root setuid ainda não funciona. A instalação a partir do .dmg foi bem-sucedida.

Também parece que o driver está procurando por vmrun quando é instalado e nunca atualiza o caminho, mesmo se você remover o Fusion por meio do barril de cerveja e instalá-lo por meio do .dmg.

Eu também estava tendo problemas como esse e, como sugeriu @robinbb , no meu caso estava sendo causado por um umask 077. Alterar meu umask para 022 resolveu isso. Eu criei um PR para que o driver faça isso sozinho e está funcionando bem para mim há algumas semanas.

Curiosamente, percebi esta manhã que a versão padrão 0.5.1 da docker-machine parece estar funcionando bem no El Capitan (que atualizei ontem), então isso pode ser menos problemático no El Capitan. Não estou completamente convencido ainda.

Acabei de ter o mesmo problema com docker-toolbox 1.12-rc3, vmware fusion 8.1.
Os scripts acima não funcionaram, mas reiniciar meu laptop sim.

Com o VMWare Fusion versão 8.1.1 (3771013), macOS Sierra 10.12 e Docker versão 8.1.1 (3771013), esse problema não ocorre mais para mim. Fechando.