Repetição do tempo limite de conexão bloqueada do Vagrant

Meu vagabundo estava funcionando perfeitamente bem ontem à noite. Acabei de ligar o PC, pressionei vagrant upe é isso que 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 está amplamente coberto na web e não consigo encontrar uma razão para isso estar ocorrendo.

Resolvi esse problema e vou responder caso alguém tenha um problema semelhante.

O que fiz foi: habilitei a GUI do Virtual box para ver que estava aguardando a entrada na inicialização para selecionar se eu queria inicializar diretamente no ubuntu ou no modo de segurança etc.

Para ativar a GUI, você deve colocar isso na sua configuração vaga Vagrantfile:

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

Quando você está preso à sua máquina vagrant 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, apenas descubra o ID da máquina em execução.

vboxmanage list runningvms

Isso resultará em algo como isto:

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

Frequentemente, a VM está simplesmente esperando você selecionar uma opção no gerenciador de inicialização. Você pode enviar o código-chave apropriado (no caso Enter) para a vm com controlvm:

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

É isso aí. Sua máquina virtual continuará o processo de inicialização.

Uma coisa a ser verificada é se a Virtualização de Hardware está ativada no BIOS da sua máquina.

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

Um laptop que eu estava montando continuava mostrando o mesmo problema. Depois de horas pesquisando, finalmente encontrei uma dica para ver se o BIOS tinha a Virtualização de Hardware ativada.

Aqui está o conteúdo da postagem que encontrei:

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

• Verifique se o firewall ou antivírus não está bloqueando o programa (o que duvido que ocorra com frequência)
• Dê um tempo à sua máquina vagabunda para que os tempos limite ocorram. Se você não tiver um PC / Mac muito rápido, a VM levará um tempo para inicializar em um estado pronto para SSH, para que ocorra o tempo limite.
• Portanto, primeiro tente deixar o tempo limite vagrant COMPLETAMENTE antes de concluir que há uma falha.
• Se o tempo limite do vagrant expirar completamente, aumente o limite de tempo limite no arquivo do vagrant para alguns minutos e tente novamente.
• Se isso ainda não funcionar, tente iniciar de forma limpa sua máquina vagrant através da interface do VirtualBox e ative a GUI da máquina com antecedência. Se a GUI não mostrar nada acontecendo (por exemplo, apenas tela preta, nenhum texto) enquanto estiver inicializando, a sua máquina vagadora terá problemas.
• Destrua a máquina inteira através da interface VB e reinstale.
• Exclua os arquivos de imagem do ubuntu na pasta Vagrant Images na pasta do usuário e faça o download e instale novamente.
• Você ainda tem um processador Intel compatível com virtualização de hardware de 64 bits? Google it. Se o fizer, verifique se não há nenhuma configuração na BIOS desativando esse recurso.
• Desative o recurso hyper-v se você estiver executando o Windows 7 ou 8. Google, como desativar.
• Verifique se você está executando um cliente habilitado para SSH. Use Git bash. Faça o download: http://git-scm.com/downloads
• Instale uma versão de 32 bits do ubuntu como trusty32 ou precision32. Basta alterar a versão no arquivo vagrant e reinstalar o vagrant no novo diretório.
• Verifique se você está usando as últimas versões do vagrant e do virtualbox. Últimos recursos: formate seu computador, reinstale o Windows e compre um processador Intel CoreAlgo.

Espero que ajude.

A solução que encontrei é verificar a opção de conexão do cabo no adaptador 1 que está conectado ao NAT. Eu realmente não sei, esta é a minha quarta caixa de vagabundos, mas esta é a única com opção de conexão a cabo não marcada e, após verificá-la, funciona.

Eu tive exatamente o mesmo problema. Eu pensei que o problema poderia estar com as chaves SSH (localização incorreta do arquivo ou qualquer outra coisa, mas eu verifiquei isso muitas vezes), mas você sempre pode adicionar na seção configure nome de usuário e senha (sem usar chaves ssh) e executar o gui para que o código Vagrantfiledeva parecer como 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 que a GUI fosse exibida, obtive uma tela preta (sem erros ou possibilidade de efetuar login ou qualquer outra coisa) e no console recebi Error: Connection timeout. Retrying...muitas vezes. Verifiquei se o VT-x (virtualização) estava ativado no BIOS, verifiquei várias combinações de versões do Virtual Box e do Vagrant juntas e de muitas caixas do Vagrant (para algumas delas não tinha tela 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 ponto crucial foi observar os ícones no VirtualBox após a execução do vagrantup (com a GUI Vagrantfilemostrada acima), como na imagem abaixo

Embora eu não tenha tido erros no VirtualPC (nenhum aviso de que o VT-x não esteja ativado), meu Vícone estava acinzentado anteriormente, o que significa que o VT-x foi desativado. Como eu disse, ele estava ativado no meu BIOS o tempo todo.

Finalmente, percebi o problema pelo HYPER-Vqual eu também instalei e habilitei para testar sites no Internet Explorer mais antigo. Eu fui para o Windows Control Panel -> Programs and functions / Softwaree escolha no menu à esquerda Turn on or Turn off Windows functions(espero que você os encontre, eu uso o Windows polonês para não saber os nomes exatos em inglês). Desliguei o Hyper-V, reiniciei o PC e depois de executar o Virtual Box e vagrant upfinalmente não tive erros, na GUI tenho a tela de login e meu Vícone parou de ficar cinza.

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

O meu estava funcionando bem e, em seguida, esse "Aviso: desconexão da conexão remota. Tentando novamente ..." repetidamente - talvez 20 vezes - até conectar. Com base nas respostas acima, eu apenas

vagrant destroy
vagrant up

e foi tudo de bom. O meu era muito simples, mas eu fiz dessa maneira cortando o arquivo Vagrant para apenas o arquivo config.vm.box = "ubuntu/trusty64"e ele ainda estava fazendo isso. É por isso que destruir e recomeçar parecia a melhor escolha. Dada a natureza apátrida dessas imagens do Vagrant, não vejo por que isso não funcionaria em todos os casos. Estou entrando nisso e ainda posso aprender que isso não é verdade.

Eu tive o mesmo problema em uma máquina Windows 8.1. O tempo limite da conexão e a ativação do GUI não foram úteis, a tela estava preta. A correção no meu caso foi desativar o "Hyper V"

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

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

Se você estiver trabalhando no Windows 8 ou 10, é isso 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 a Inicialização avançada (Vá para Inicialização avançada - 'reiniciar agora' - 'solucionar problemas' - 'opção avançada' - 'Configuração de firmware UEFI' - 'Reiniciar')
   • Dentro da janela do BIOS - Vá para o menu / guia 'Avançado' - Ative 'Intel Virtual Technology'
   • Saída segura.

Eu tive um problema com isso com uma caixa existente (não tenho certeza do que mudou), mas pude conectar via SSH, mesmo que a caixa do Vagrant não tenha sido inicializada. Por acaso minha chave SSH mudou de alguma forma.

Na pasta raiz vagrant que eu corri, vagrant ssh-configme disse onde estava o arquivo-chave. Abri isso com puttygen e, em seguida, me deu uma nova chave.

No meu convidado Linux, editei ~/.ssh/authorized_keyse soltei a nova chave pública lá.

Tudo está funcionando novamente - por enquanto!

Eu tive o mesmo problema depois de excluir esta linha do meu Vagrantfile:

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

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

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

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

Para depurar o problema, execute uma --debugopção ou o seguinte:

VAGRANT_LOG=debug vagrant up

Se não houver nada óbvio, tente conectar-se a ele a partir de outro terminal, por vagrant sshou 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).

Caso contrário, verifique os processos em execução (por exemplo:) vagrant ssh -c 'pstree -a'ou verifique o seu sshd_config.

Se ele é descartável VM, você pode sempre tentar destroy-lo e upele novamente.

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

Para obter mais informações, consulte a página Depuração e solução de problemas .

Eu tive o mesmo problema, mas nenhuma das outras respostas resolveu completamente o meu problema. Responder por @Kiee foi útil, embora tudo que eu pudesse ver na GUI fosse uma tela preta (com sublinhado no canto superior esquerdo, esse problema no Virtual Box também foi levantado separadamente no estouro da pilha, novamente nada ajudou).

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

Mais precisamente, eu tinha uma caixa de outra pessoa com o Debian de 64 bits, mas a Virtual Box insistia em tratá-la como 32 bits, o que eu não percebi. 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 o tempo limite) e executar

vagrant halt

sua máquina virtual não será destruída; portanto, você pode vê-la no menu do Virtual Box, mas será desligada para poder alterar as configurações. Escolha sua máquina no menu, clique em 'Configurações' -> 'Geral' e escolha 'Versão' adequada, para mim era 'Debian (64 bits)'. Após esse tipo vagrant upnovamente.

Se esse for o seu caso (ou alterações diferentes em 'Configurações' resolverem seu problema), você poderá criar uma nova caixa a partir da que foi reparada, digitando

vagrant package --output mynew.box

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

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

1. vagrant upnão consegui encontrar meu ssh ' id_rsa ' (porque ainda não o tinha naquela época): corri ssh-keygen -t rsa -b 4096 -C "myemailaddress@mydomain.com", com base no artigo deste GitHub , e voilá, o conduzi;

2. Então, tive o mesmo problema desta pergunta " Aviso: a conexão expirou. Tentando novamente ... ", eternamente ...: Então, depois de ler muito, reiniciei o sistema e verifiquei o BIOS (F2 para obter lá, no PC) e a Virtualização desativada . Eu habilitei isso, salvei e iniciei o sistema mais uma vez, para verificar se ele mudou alguma coisa.

Depois disso, vagrant upfuncionou como um encanto! São 4 da manhã, mas está funcionando! Que legal, né? : 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 podia deixar de vir aqui e deixar minha palavra ... outra informação importante é: Eu estava tentando configurar 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!

Eu estava testando uma pasta montada na minha VM vagrant adicionando uma nova entrada no /etc/fstab. Mais tarde, desconectei, corri vagrantemente, mas quando corri vagrant up, obtive:

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

Li todas essas postagens e tentei todas as que pareciam relevantes para o meu caso (exceto a destruição de vagabundos, o que certamente resolveria meu problema, mas era o último recurso no meu caso). A postagem de @Kiee me deu a ideia de tentar inicializar minha VM diretamente da GUI do VirtualBox. Durante o processo de inicialização, a VM se interrompeu e me perguntou se eu queria pular a montagem da pasta de teste à qual havia adicionado anteriormente /etc/fstab. (É por isso que o vagrant não conseguiu inicializar a VM.) Após responder 'NÃO', a VM não inicializou. Entrei, removi a linha danada do meu fstab e desliguei a VM.

Depois que o vagabundo foi capaz de inicializar muito bem.

Leve embora? Se de repente um vagabundo não puder inicializar novamente na sua VM, tente inicializar diretamente do provedor (VirtualBox no meu caso). Provavelmente, sua bota está pendurada por algo totalmente não relacionado ao SSH.

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

Mudei para x32 e funcionou (hashicorp / preciso32).

Talvez essa seja uma resposta muito simples para ajudar muitas pessoas, mas vale a pena tentar se você não tiver: Faça uma "interrupção vaga" em vez de uma "suspensão vaga" e reinicie a VM com "abertura rápida".

Eu acho que meu problema foi devido a algum processo "kworker" ficar com erros e constantemente atingir o tempo limite na VM e, portanto, fazer uma reinicialização forte pareceu recarregar o processo corretamente, enquanto um salvamento e restauração estavam apenas restaurando o processo quebrado em seu estado quebrado.

Eu consegui isso ao executar o vagrant / VirtualBox dentro do VirtualBox. Eu resolvi isso executando a máquina vagrant na máquina host.

Descobri que no MacOS com o VirtualBox, adicionar isso ao Vagrantfile permitirá que você vá além:

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

A instalação de um ubuntu32 bits em um AMD64 bits fez o truque. Não tenho acesso aos BIOs, pois é um ambiente restrito, mas ainda consegui fazê-lo funcionar com o ubuntu / trusty32 em vez 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 vagrant e caixa virtual.

Estou no Windows 10 e o que fiz, desinstalei o vagrant and virtual box

Em seguida, instale uma versão antiga do virtual box especificamente versão 4.3.38 (Instale o pacote de extensão também para esta versão)

Em seguida, instalou a cópia mais recente do vagrant (1.8.5 no momento)

Depois disso funcionou.

Se você não deseja habilitar a GUI e depois desabilitá-la mais tarde, também pode instalar o pacote de extensão do 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 conectar-se à sua caixa sob demanda, sem que o SSH precise estar em execução ou a GUI aberta o tempo todo.

Mais uma solução possível para os 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. As interfaces de rede entre o VMware e o VirtualBox eram aparentemente conflitantes

Eu enfrentei o mesmo problema. Eu reparei isso, permitindo Virtualizationa partir BIOSde configuração.

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) da BIOS.

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

No meu caso, fornecendo um endereço IP estático, simplesmente resolvi o problema:

config.vm.network "private_network", ip: "192.168.50.50"

FWIW - Meu problema foi devido ao uso de um arquivo de configuração muito antigo, em vez de um mais novo. O uso do novo arquivo de configuração (e, portanto, o DSL ajustado / alterado) corrigiu meus problemas instantaneamente.

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

Em vez de pressionar a tecla Ctrl para fora da caixa virtual, como costuma fazer sempre que ssh em alguma coisa, acredito que o vagrant prefere que você entre em outro terminal e faça:

vagrant halt

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