Tempo limite de conexão preso do Vagrant tentando novamente

Meu vagrant estava funcionando perfeitamente bem na noite passada. Acabei de ligar o PC, acertar o vagrant up , e é isso que eu recebo:

 ==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat default: Adapter 2: hostonly ==> default: Forwarding ports... default: 22 => 2222 (adapter 1) ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2222 default: SSH username: vagrant default: SSH auth method: private key default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... 

Alguém já teve isso antes? O vagrant ainda não é amplamente abordado na web e não consigo encontrar uma razão para que isso esteja ocorrendo.

Eu resolvi esse problema e responderei caso alguém tenha um problema semelhante.

O que eu fiz foi: eu habilitei a checkbox GUI do Virtual para ver que ele estava esperando pela input na boot para selecionar se eu queria inicializar diretamente para o ubuntu ou safemode etc.

Para ligar a GUI você tem que colocar isso no seu Vagrantfile config vagrant:

 config.vm.provider :virtualbox do |vb| vb.gui = true end 

Quando você está preso à sua máquina vagante da maneira descrita acima, não há necessidade de inicializar no modo gui (e é impossível sem um servidor X).

Enquanto sua VM está inicializando, em uma janela de terminal separada, basta descobrir o id do computador em execução.

 vboxmanage list runningvms 

Isso resultará em algo como isto:

 "projects_1234567890" {5cxxxx-cxxx-4xxx-8xxx-5xxxxxxxxxx} 

Muitas vezes, a VM está simplesmente esperando por você para selecionar uma opção no bootloader. Você pode enviar o keycode apropriado (no caso, Enter ) para o vm com controlvm :

 vboxmanage controlvm projects_1234567890 keyboardputscancode 1c 

É isso aí. Sua máquina virtual continuará o processo de boot.

Uma coisa a verificar é se a virtualização de hardware está habilitada no BIOS da sua máquina.

Meu problema é a mesma sequência de tempos limite, mas só consegui ver uma canvas preta na GUI.

Um laptop que eu estava montando continuava mostrando o mesmo problema. Depois de horas de busca, finalmente encontrei uma dica para ver se o BIOS tinha habilitado a virtualização de hardware.

Aqui está o conteúdo do post que encontrei:

Vejo que ainda há alguns usuários que estão enfrentando esse problema. Então, tentarei resumir uma lista abaixo de algumas possíveis soluções para o problema de tempo limite do SSH:

  • Verifique se o seu firewall ou antivírus não está bloqueando o programa (o que duvido que aconteça com frequência)
  • Dê à sua máquina vagante algum tempo para os tempos de espera acontecerem. Se você não tem um PC / Mac muito rápido, a VM levará algum tempo para inicializar em um estado pronto para SSH, então os tempos limite irão acontecer.
  • Portanto, primeiro tente deixar o timeout do vagrant COMPLETAMENTE antes de concluir que existe uma falha.
  • Se o vagrant expirar completamente, aumente o limite de tempo limite no arquivo vagante para alguns minutos e tente novamente.
  • Se isso ainda não funcionar, tente limpar a sua máquina vagabunda através da interface do VirtualBox e habilitar a GUI da máquina de antemão. Se a GUI não mostrar nada acontecendo (ou seja, apenas canvas preta, sem texto) enquanto está inicializando, então sua máquina errante tem problemas.
  • Destrua a máquina inteira através da interface do VB e reinstale.
  • Exclua os arquivos de imagem do Ubuntu na pasta Vagrant Images na pasta do usuário e faça o download novamente e instale.
  • Você ainda tem um processador Intel que suporte virtualização de hardware de 64 bits? Google isso. Se fizer isso, certifique-se de que não haja nenhuma configuração em sua BIOS desativando esse recurso.
  • Desative o recurso hyper-v se você estiver executando o Windows 7 ou o 8. Google como desabilitar.
  • Certifique-se de estar executando um cliente habilitado para SSH. Use o Git bash. Download: http://git-scm.com/downloads
  • Instale uma versão de 32 bits do Ubuntu como trusty32 ou precise32. Apenas mude a versão no arquivo vagrant e reinstale o vagrant no novo diretório.
  • Certifique-se de estar usando as versões mais recentes do vagrant e do virtualbox. Últimos resources: Formate o seu computador, reinstale o Windows e compre um processador de núcleo inteligente Intel.

Espero que ajude.

A solução que encontrei é verificar a opção de conexão a cabo no adaptador 1 que está conectado ao NAT. Eu realmente não sei, esta é a minha quarta checkbox vagabunda, mas esta é a única com opção de conexão a cabo não verificada, e ao verificar, funciona. Ligação por cabo NAT

Eu tive exatamente o mesmo problema. Eu pensei que o problema poderia ser com chaves SSH (localização errada do arquivo ou outra coisa, mas eu verifiquei muitas vezes), mas você sempre pode adicionar na configuração username e senha (sem usar chaves ssh) e executar gui para que o código no Vagrantfile parece mais ou menos como abaixo:

 Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.ssh.username = "vagrant" config.ssh.password = "vagrant" config.vm.provider "virtualbox" do |vb| vb.gui = true end end 

No meu caso, mesmo se GUI foi exibido eu tenho canvas preta (sem erros ou possibilidade de login ou qualquer outra coisa) e no console eu tenho o Error: Connection timeout. Retrying... Error: Connection timeout. Retrying... muitas vezes. Eu me certifiquei de ter o VT-x (virtualização) ativado no BIOS, verifiquei muitas combinações de versões do Virtual Box e do Vagrant e muitas checkboxs do Vagrant (para algumas delas eu não tinha canvas preta na GUI, mas ainda tinha conexão problemas). Finalmente atualizei o VirtualBox e o Vagrant novamente para as últimas versões e o problema ainda ocorreu.

O mais importante era olhar para icons no VirtualBox depois de executar o vagrantup (com GUI no Vagrantfile como eu mostrei acima) como na imagem abaixo

insira a descrição da imagem aqui

Embora eu não tivesse erros no VirtualPC (sem avisos de que o VT-x não está habilitado), meu ícone V estava cinza antes, o que significa que o VT-x estava desativado. Como eu disse, eu tinha ativado na minha BIOS o tempo todo.

Por fim, percebi que o problema poderia ser o HYPER-V que também instalei e testei sites no Internet Explorer mais antigo. Eu fui ao Control Panel -> Programs and functions / Software Windows Control Panel -> Programs and functions / Software e escolha no menu à esquerda Turn on or Turn off Windows functions (espero que você vai encontrá-los, eu uso o Windows polonês, então não sei nomes exatos em inglês). Eu desliguei o Hyper-V, reiniciei o PC e depois de executar o Virtual Box e vagrant up eu finalmente não tive nenhum erro, na GUI eu tenho a canvas de login e o meu ícone V parou para ficar cinza.

Perdi muito tempo resolvendo esse problema (e muitas reinicializações do PC), então espero que isso possa ser útil para qualquer um que tenha problemas no Windows – verifique se o Hyper-V está desativado no Painel de Controle.

O meu estava funcionando bem e, em seguida, este “Aviso: conexão remota desconectar. Tentando novamente …” mais e mais – talvez 20 vezes – até que ele conectado. Com base nas respostas acima eu apenas

 vagrant destroy vagrant up 

e foi tudo de bom. O meu foi muito simples, mas eu fiz dessa forma, reduzindo o Vagrantfile para apenas o config.vm.box = "ubuntu/trusty64" e ainda estava fazendo isso. Então é por isso que destruir e começar de novo parecia a melhor escolha. Dada a natureza sem estado dessas imagens Vagrant, não vejo por que isso não funcionaria em todos os casos. Estou apenas entrando nisso e ainda posso aprender que isso não é verdade.

Eu experimentei o mesmo problema em uma máquina com Windows 8.1. O tempo limite de conexão e a ativação da GUI não foram úteis, a canvas estava preta. A correção no meu caso foi desativar o “Hyper V”

Cite a documentação do Vagrant https://docs.vagrantup.com/v2/hyperv/index.html

Aviso: a ativação do Hyper-V fará com que o VirtualBox, o VMware e qualquer outra tecnologia de virtualização não funcionem mais. Veja esta postagem no blog https://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx para obter uma maneira fácil de criar uma input de boot para inicializar o Windows sem o Hyper-V ativado, se houver momentos em que você precisará de outros hipervisores.

Se você está trabalhando no Windows 8 ou 10, isso é o que funcionou para mim:

  1. Altere as configurações do BIOS para permitir a virtualização de 64 bits.
  2. Aqui está como:
    • Reinicie o PC usando o Advanced Startup (Vá para Advanced Startup -‘reiniciar agora ‘-‘ solucione problemas ‘-‘ advanced option ‘-‘ UEFI Firmware Setting ‘-‘ Restart ‘)
    • Dentro da janela do BIOS – Vá para o menu ‘Avançado’ / aba – Habilite ‘Intel Virtual Technology’
    • Saída segura.

Eu tive um problema com isso com uma checkbox existente (não sei o que mudou), mas eu poderia conectar via SSH, mesmo que a checkbox do Vagrant não arrancasse. Por acaso minha chave SSH mudou de alguma forma.

Da pasta raiz do vagrant eu corri o vagrant ssh-config que me dizia onde estava o arquivo de chave. Eu abri isso com puttygen e, em seguida, deu-me uma nova chave.

No meu convidado Linux, eu editei ~/.ssh/authorized_keys e deixei cair a nova chave pública lá.

Tudo está funcionando novamente – por enquanto!

Eu tive o mesmo problema depois que eu deletei esta linha do meu Vagrantfile:

 config.vm.network "private_network", type: "dhcp" 

VM carregou bem depois que eu coloquei esta linha de volta.

Eu tive o mesmo problema, mas nenhuma das outras respostas resolveu totalmente o meu problema. Resposta por @Kiee foi útil, embora tudo que eu podia ver na GUI era uma canvas preta (com sublinhado no canto superior esquerdo, esse problema no Virtual Box também foi criado separadamente no estouro de pilha, novamente nada ajudou).

Eventualmente, uma solução provou ser muito simples: verifique a versão de sua máquina virtual.

Mais precisamente, eu tinha uma checkbox de outra pessoa com Debian de 64 bits, mas a Virtual Box insistiu em tratá-la como 32 bits, o que eu não notei. Para alterá-lo, abra o Virtual Box, abra o terminal e execute

 vagrant up 

espere pela linha

 default: SSH auth method: private key 

agora você pode pressionar Ctrl + C (ou esperar por timeout) e executar

 vagrant halt 

sua máquina virtual não será destruída, então você pode vê-la no menu do Virtual Box, mas será desligada, para que você possa alterar as configurações. Escolheu sua máquina no menu, clique em ‘Configurações’ -> ‘Geral’ e escolheu ‘Versão’ apropriada, para mim foi ‘Debian (64-bit)’. Após este tipo vagrant up novamente.

Se este for um caso para você (ou diferentes mudanças em ‘Configurações’ resolveram seu problema), você pode criar uma nova checkbox a partir do reparo

 vagrant package --output mynew.box 

Mais alguns detalhes: o host de 32 bits do Ubuntu 12.04, o convidado de 64 bits da Debian 8.1, o Virtual Box 5.0.14, o Vagrant 1.8.1

Há muitas boas respostas aqui, e eu não consegui ler tudo, mas acabei de dar minha pequena contribuição também. Eu tive dois problemas diferentes:

  1. vagrant up não foi capaz de encontrar o meu ssh ‘ id_rsa ‘ (porque eu não o tinha ainda, na época): Eu corri ssh-keygen -t rsa -b 4096 -C "myemailaddress@mydomain.com" , com base neste artigo do GitHub , e voilá, passou por isso;

  2. Então, eu tenho o mesmo problema desta pergunta ” Aviso: Conexão esgotada. Tentando novamente … “, eternamente …: Então, depois de ler muito, eu reiniciei o meu sistema e olhei para o meu BIOS (F2 para obter lá, no PC), e havia virtualização desativada . Eu habilitei isso, salvei e iniciei o sistema novamente, para verificar se ele mudou alguma coisa.

Depois disso, vagrant up funcionou como um encanto! São 4 da manhã, mas está funcionando! Que legal, hã? : D Como eu sei que existem muito poucos desenvolvedores masoquistas como eu, que tentariam isso no Windows, especialmente no Windows 10 , eu simplesmente não poderia não esquecer de vir aqui e deixar minha palavra … outra informação importante, é que, Eu estava tentando montar o Laravel 5 , usando Homestead, VirtualBox, compositor etc. Ele funcionou. Então, espero que esta resposta ajude como esta pergunta e as respostas me ajudaram. Meus melhores desejos. Tchau!

O tempo limite da conexão SSH durante a boot inicial pode estar relacionado a vários motivos, como:

  • verificar se a virtualização está habilitada no BIOS (como por comentário ),
  • o sistema aguarda a interação do usuário (por exemplo, partição de compartilhamento não está pronta ),
  • incompatibilidade de sua chave privada (verifique a configuração via vagrant ssh-config ),
  • o processo de boot leva muito mais tempo (tente aumentar o config.vm.boot_timeout ),
  • está inicializando a partir da unidade errada (por exemplo, do instalador ISO),
  • Configuração incorreta do firewall da VM (por exemplo, configuração do iptables ),
  • regras de firewall locais, conflito de porta ou conflito com um software de VPN,
  • sshd configuração.

Para depurar o problema, por favor, execute uma opção --debug ou como:

 VAGRANT_LOG=debug vagrant up 

Se não houver nada óbvio, tente se conectar a ele a partir de outro terminal, por vagrant ssh ou por:

 vagrant ssh-config > vagrant-ssh; ssh -F vagrant-ssh default 

Se o SSH ainda falhar, tente executá-lo com uma GUI (por exemplo, config.gui = true ).

Se não estiver, verifique os processos em execução (por exemplo: vagrant ssh -c 'pstree -a' ) ou verifique seu sshd_config .


Se for VM descartável, você sempre pode tentar destroy lo e up lo novamente.

Você também deve considerar atualizar seu Vagrant e Virtualbox.


Para mais informações, consulte a página Depuração e Solução de Problemas .

Eu estava testando uma pasta montada em minha VM vagante, adicionando uma nova input em /etc/fstab . Mais tarde eu fiz o logout, fiz uma parada vagante, mas quando eu corri vagrant up eu peguei:

 SSH auth method: private key Warning: Remote connection disconnect. Retrying... 

Eu li todos esses posts e tentei todos os que pareciam relevantes para o meu caso (exceto para o vagrant destroy, que certamente teria resolvido o meu problema, mas foi um último recurso no meu caso). A postagem do @Kiee me deu a ideia de tentar inicializar minha VM diretamente a partir da GUI do VirtualBox. Durante o processo de boot, a VM parou e estava me perguntando se eu queria pular a assembly da pasta de teste que eu havia adicionado anteriormente em /etc/fstab . (É por isso que o vagrant não pôde inicializar a VM.) Depois de responder ‘NO’ a VM inicializou sem problemas. Eu entrei, removi a linha perversa do meu fstab e desliguei a VM.

Depois que o vagrant foi capaz de arrancar muito bem.

Leve embora? Se de repente vagrant não pode inicializar de volta em sua VM, tente inicializar diretamente do provedor (VirtualBox no meu caso). É provável que a sua boot esteja pendente de algo totalmente não relacionado ao SSH.

Eu tive o mesmo problema quando eu estava usando x64 box (chef / ubuntu-14.04).

Eu mudei para x32 e funcionou (hashicorp / precise32).

Talvez esta seja uma resposta muito simples para ajudar muitas pessoas, mas vale a pena tentar se você não tiver: Faça uma “parada vagante” em vez de uma “suspensão vagante” e então reinicie a VM com “vagrant up”.

Eu acho que o meu problema foi devido a alguns “kworker” processo ficando buggy e constantemente o tempo limite na VM e assim fazendo um hard reboot parecia recarregar o processo corretamente enquanto um salvamento e restauração era apenas restaurar o processo quebrado em seu estado quebrado.

Eu tenho isso quando executando vagrant / VirtualBox dentro do VirtualBox. Eu resolvi isso executando a máquina vagrant na máquina host.

Instalando um ubuntu32 bits em um AMD64 bits fez o truque. Eu não tenho access aos BIOs, já que é um ambiente restrito, mas ainda assim consegui fazê-lo funcionar com o ubuntu / trusty32 ao invés do ubuntu / trusty64

Usando o Vagrant 1.6.3 com o VirtualBox 4.3.15 no Windows 7 SP1

espero que ajude.

Para mim, foi a compatibilidade entre a checkbox vagabunda e virtual.

Eu estou no Windows 10 e o que eu fiz eu desinstalei checkbox vagrant e virtual

Em seguida, instale uma versão antiga da checkbox virtual especificamente a versão 4.3.38 (instale o pacote de extensão também para esta versão)

Então instalei a última cópia do vagrant (1.8.5 no momento)

Depois disso, funcionou.

Descobri que no MacOS com o VirtualBox adicionando isso ao Vagrantfile, você pode ir mais longe:

 config.vm.provider 'virtualbox' do |vb| vb.customize ['modifyvm', :id, '--cableconnected1', 'on'] end 

Se você não quiser ativar a GUI e depois desativá-la posteriormente, também poderá instalar o pacote de extensões da Oracle:

http://www.oracle.com/technetwork/server-storage/virtualbox/downloads/index.html#extpack

Em seguida, coloque isso no seu Vagrantfile para ativar o VRDP:

 vb.customize ["modifyvm", :id, "--vrde", "on"] 

Agora você pode usar o RDP para se conectar à sua checkbox sob demanda sem precisar executar o SSH ou a GUI abrir o tempo todo.

Mais uma solução possível para usuários do provedor VMware: Para mim, o problema foi resolvido após a remoção de uma instalação paralela do VirtualBox na mesma máquina host. Interfaces de rede entre VMware e VirtualBox eram aparentemente conflitantes

Eu enfrentei o mesmo problema. Eu consertei isso ativando a Virtualization partir da configuração do BIOS .

Exclua o arquivo:

 C:\Users\UserName\\.vagrant.d\insecure_private_key 

Então corra:

 vagrant up 

O que funcionou para mim foi permitir a virtualização de 64 bits em um sistema operacional de 64 bits (Ubuntu 13.10) do BIOS.

Verifique a virtualização da sua CPU na configuração do BIOS está ativada.

FWIW – Meu problema foi devido ao uso de um arquivo de configuração muito antigo em vez de um mais novo. Usando o novo arquivo de configuração (e, portanto, ajustada / modificada DSL) resolvi meus problemas instantaneamente.

O que me ajudou foi a habilitação da virtualização na BIOS, porque a máquina não inicializou.

Ao invés de ctrl-d-ing fora da checkbox virtual como eu estou acostumado a fazer sempre que eu estiver em qualquer coisa, eu acredito que vagrant preferiria que você entrasse em outro terminal e fizesse um:

vagrant halt

para parar a checkbox. Então não haverá problemas para voltar ao VB.

Eu enfrentei o mesmo problema, porém não das soluções mencionadas funcionou para mim! Eu resolvi isso rebaixando o Vagrant para 1.6.2 e agora funciona!