Tentativo di timeout di connessione bloccato Vagrant

Il mio vagabondo stava lavorando perfettamente bene ieri sera. Ho appena acceso il PC, colpito vagrant upe questo è quello che ottengo:

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

Qualcuno l'ha mai fatto prima? Vagrant non è ancora ampiamente trattato sul web e non riesco a trovare un motivo per cui ciò sta accadendo.

Ho risolto questo problema e risponderò nel caso in cui qualcun altro abbia un problema simile.

Quello che ho fatto è stato: ho abilitato la GUI di Virtual box a vedere che era in attesa di input all'avvio per selezionare se volevo avviare direttamente su Ubuntu o Safemode ecc.

Per attivare la GUI devi metterlo nella tua configurazione vagabonda Vagrantfile:

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

Quando sei bloccato con la tua macchina vagabonda nel modo sopra descritto, non è necessario eseguire l'avvio in modalità gui (ed è impossibile senza un server X).

Mentre la VM si avvia, in una finestra terminale separata, basta scoprire l'id della macchina in esecuzione.

vboxmanage list runningvms

Ciò si tradurrà in qualcosa del genere:

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

Abbastanza spesso, la VM sta semplicemente aspettando che tu selezioni un'opzione nel bootloader. È possibile inviare il codice chiave appropriato (nel caso, Enter) al VM con controlvm:

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

Questo è tutto. La tua macchina virtuale continuerà il processo di avvio.

Una cosa da verificare è se la virtualizzazione hardware è abilitata nel BIOS della macchina.

Il mio problema è la stessa serie di timeout ma ho potuto vedere solo una schermata nera nella GUI.

Un laptop che stavo installando continuava a mostrare lo stesso problema. Dopo ore di ricerche ho finalmente trovato un suggerimento per vedere se il BIOS aveva la virtualizzazione hardware abilitata.

Ecco il contenuto del post che ho trovato:

Vedo che ci sono ancora alcuni utenti che riscontrano questo problema. Quindi, cercherò di riassumere un elenco di seguito di alcune possibili soluzioni al problema del timeout SSH:

• Assicurati che il tuo firewall o antivirus non stia bloccando il programma (che dubito accadrà spesso)
• Concedi alla tua macchina vagabonda un po 'di tempo perché avvengano i timeout. Se non si dispone di un PC / Mac molto veloce, la VM impiegherà del tempo ad avviarsi in uno stato SSH pronto, quindi si verificheranno i timeout.
• Pertanto, provare innanzitutto a lasciare COMPLETAMENTE il timeout del vagabondo prima di concludere che si è verificato un errore.
• Se vagrant scade completamente, aumenta il limite di timeout nel file vagrant a qualche minuto e riprova.
• Se il problema persiste, provare a ripulire il computer vagabondo tramite l'interfaccia VirtualBox e abilitare preventivamente la GUI del computer. Se la GUI non mostra nulla (ad es. Solo una schermata nera, nessun testo) durante l'avvio, la tua macchina vagabonda ha dei problemi.
• Distruggi l'intero computer attraverso l'interfaccia VB e reinstallalo.
• Elimina i file immagine di Ubuntu nella cartella Immagini Vagrant nella cartella utente e scarica e installa nuovamente.
• Hai anche un processore Intel che supporta la virtualizzazione hardware a 64 bit? Google. In tal caso, assicurarsi che non vi siano impostazioni nel BIOS che disabilitano questa funzione.
• Disabilitare la funzione hyper-v se si esegue Windows 7 o 8. Google come disabilitare.
• Assicurati di essere in esecuzione attraverso un client abilitato SSH. Usa Git bash. Scarica: http://git-scm.com/downloads
• Installa una versione a 32 bit di Ubuntu come trusty32 o precise32. Basta cambiare la versione nel file vagrant e reinstallare vagrant nella nuova directory.
• Assicurati di utilizzare le ultime versioni di Vagrant e Virtualbox. Ultimi resort: formatta il tuo computer, reinstalla Windows e acquista un processore isomething Intel Core.

Spero che aiuti.

La soluzione che ho trovato è quella di verificare l'opzione di connessione del cavo nell'adattatore 1 collegato a NAT. Davvero non lo so, questa è la mia quarta scatola di vagabondi, ma questa è l'unica con l'opzione di connessione via cavo non selezionata e, dopo averla verificata, funziona.

Ho avuto esattamente lo stesso problema. Ho pensato che il problema potrebbe essere con le chiavi SSH (localizzazione errata del file o qualcos'altro ma l'ho verificato molte volte) ma puoi sempre aggiungere nella sezione di configurazione nome utente e password (senza usare le chiavi ssh) ed eseguire la GUI in modo che il codice in Vagrantfiledovrebbe apparire come più o meno come di seguito:

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

Nel mio caso, anche se è stata visualizzata la GUI, ho ottenuto una schermata nera (nessun errore o possibilità di accesso o altro) e in console ho avuto Error: Connection timeout. Retrying...molte volte. Mi sono assicurato di avere VT-x (virtualizzazione) abilitato nel BIOS, ho controllato molte combinazioni di versioni di Virtual Box e Vagrant insieme e molte scatole di Vagrant (per alcune di esse non avevo lo schermo nero nella GUI ma avevo ancora la connessione i problemi). Alla fine ho aggiornato VirtualBox e Vagrant di nuovo alle ultime versioni e il problema si è ancora verificato.

La cosa cruciale era guardare le icone in VirtualBox dopo aver eseguito vagrantup (con la GUI Vagrantfilecome ho mostrato sopra) come nell'immagine qui sotto

Anche se non ho riscontrato errori in VirtualPC (nessun avviso che VT-x non è abilitato) la mia Vicona era precedentemente grigia quindi significa che VT-x era disabilitato. Come ho detto, l'ho sempre abilitato nel mio BIOS.

Alla fine mi sono reso conto del problema con HYPER-Vcui ho anche installato e abilitato a testare siti su Internet Explorer meno recente. Sono andato a Windows Control Panel -> Programs and functions / Softwaree ho scelto dal menu a sinistra Turn on or Turn off Windows functions(spero che li troverai, io uso Windows polacco quindi non conosco i nomi inglesi esatti). Ho spento Hyper-V, riavviato il PC e dopo aver eseguito Virtual Box e alla vagrant upfine non ho riscontrato errori, nella GUI ho la schermata di accesso e la mia Vicona non è più grigia.

Ho perso molto tempo a risolvere questo problema (e molti riavvii del PC), quindi spero che ciò possa essere utile a chiunque abbia problemi su Windows: assicurati di avere Hyper-V disattivato nel tuo Pannello di controllo.

Il mio funzionava bene e poi questo "Avviso: disconnessione della connessione remota. Riprovare ..." più e più volte - forse 20 volte - fino a quando non si è collegato. Sulla base delle risposte sopra ho appena

vagrant destroy
vagrant up

ed è andato tutto bene. Il mio era molto semplice, ma l'ho fatto in quel modo tagliando il Vagrantfile a solo config.vm.box = "ubuntu/trusty64"e lo stava ancora facendo. Ecco perché distruggere e ricominciare sembrava la scelta migliore. Data la natura apolide di queste immagini di Vagrant, non vedo perché non funzionerebbe in ogni caso. Sto solo entrando in questo e potrei ancora imparare che non è vero.

Ho riscontrato lo stesso problema su un computer Windows 8.1. Il timeout della connessione e l'abilitazione della GUI non erano affatto utili, lo schermo era nero. La correzione nel mio caso stava disabilitando "Hyper V"

Citazione dalla documentazione di Vagrant https://docs.vagrantup.com/v2/hyperv/index.html

Avvertenza: l'attivazione di Hyper-V farà sì che VirtualBox, VMware e qualsiasi altra tecnologia di virtualizzazione non funzionino più. Vedi questo post sul blog https://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx per un modo semplice per creare una voce di avvio per avviare Windows senza Hyper-V abilitato, se ci saranno occasioni in cui avrai bisogno di altri hypervisor.

Se stai lavorando su Windows 8 o 10, questo è ciò che ha funzionato per me:

1. Modifica le impostazioni del BIOS per consentire la virtualizzazione a 64 bit.
2. Ecco come:
   • Riavvia il PC utilizzando Advanced Startup (vai a Advanced Startup -'restart now '-' troubleshoot '-''advanced option'-' UEFI Firmware Setting '-' Restart ')
   • Finestra BIOS interna - Vai al menu / scheda "Avanzate" - Abilita "Tecnologia virtuale Intel"
   • Salva ed esci.

Ho avuto un problema con questo con un box esistente (non sono sicuro di cosa sia cambiato), ma sono riuscito a connettermi tramite SSH, anche se il box Vagrant non è riuscito ad avviarsi. Accade che la mia chiave SSH sia cambiata in qualche modo.

Ho eseguito dalla vagrant cartella principale che mi ha vagrant ssh-configdetto dove si trovava il file chiave. Ho aperto questo con puttygen e poi mi ha dato una nuova chiave.

Sul mio guest Linux, ho modificato ~/.ssh/authorized_keyse lasciato cadere la nuova chiave pubblica lì dentro.

Tutto funziona di nuovo - per ora!

Ho avuto lo stesso problema dopo aver eliminato questa riga dal mio Vagrantfile:

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

VM caricato correttamente dopo aver rimesso questa riga.

Il timeout della connessione SSH durante l'avvio iniziale può essere correlato a una varietà di motivi come:

• controlla se la virtualizzazione è abilitata nel BIOS (come da commento ),
• il sistema attende l'interazione dell'utente (ad es. la partizione di condivisione non è pronta ),
• mancata corrispondenza della chiave privata (controlla la configurazione tramite vagrant ssh-config),
• il processo di avvio richiede molto più tempo (prova ad aumentare config.vm.boot_timeout),
• si sta avviando dall'unità sbagliata (ad es. dall'ISO dell'installatore),
• iptablesConfigurazione errata del firewall VM (ad es. Configurazione ),
• regole firewall locali, conflitti di porte o conflitti con un software VPN,
• sshd errori di configurazione.

Per eseguire il debug del problema, esegui --debugun'opzione o simile:

VAGRANT_LOG=debug vagrant up

Se non c'è nulla di ovvio, prova a connetterti da un altro terminale, con vagrant ssho tramite:

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

Se l'SSH continua a non funzionare, provare a eseguirlo con una GUI (ad es config.gui = true.).

In caso contrario, controlla i processi in esecuzione (ad esempio vagrant ssh -c 'pstree -a':) o verifica il tuo sshd_config.

Se è una macchina virtuale usa e getta, puoi sempre provare ad destroyessa e di upnuovo.

Dovresti anche prendere in considerazione l'aggiornamento di Vagrant e Virtualbox.

Per ulteriori informazioni, consultare la pagina Debug e risoluzione dei problemi .

Ho avuto lo stesso problema, ma nessuna delle altre risposte ha risolto completamente il mio problema. La risposta di @Kiee è stata utile, anche se tutto quello che ho potuto vedere nella GUI era una schermata nera (con il trattino basso in alto a sinistra, anche questo problema in Virtual Box è stato sollevato separatamente in overflow dello stack, di nuovo nulla ha aiutato).

Alla fine, una soluzione si è rivelata molto semplice: controlla la versione della tua macchina virtuale.

Più precisamente, ho avuto un box da qualcun altro con Debian a 64 bit, ma Virtual Box ha insistito nel trattarlo come a 32 bit, cosa che non avevo notato. Per cambiarlo, apri Virtual Box, quindi apri il terminale ed esegui

vagrant up

aspetta la linea

default: SSH auth method: private key

ora puoi premere ctrl + C (o attendere il timeout) ed eseguire

vagrant halt

la tua macchina virtuale non verrà distrutta, quindi puoi vederla nel menu di Virtual Box, ma verrà spenta, quindi puoi modificare le impostazioni. Scegli la tua macchina nel menu, fai clic su 'Impostazioni' -> 'Generale' e scegli la 'Versione' corretta, per me era 'Debian (64-bit)'. Dopo questo tipo di vagrant upnuovo.

Se questo è il tuo caso (o le diverse modifiche in "Impostazioni" hanno risolto il tuo problema), puoi creare una nuova casella da quella riparata digitando

vagrant package --output mynew.box

Alcuni dettagli: host Ubuntu 12.04 a 32 bit, guest Debian 8.1 a 64 bit, Virtual Box 5.0.14, Vagrant 1.8.1

Ci sono molte buone risposte qui, e non riuscivo a leggere tutto, ma sono passato solo per dare il mio piccolo contributo. Ho avuto 2 diversi problemi:

1. vagrant upnon sono riuscito a trovare il mio ssh " id_rsa " (perché non lo avevo ancora, a quel tempo): ho corso ssh-keygen -t rsa -b 4096 -C "myemailaddress@mydomain.com", basandomi su questo articolo di GitHub , e voilá, ci sono passato;

2. Quindi, ho avuto lo stesso problema di questa domanda " Avviso: Timeout della connessione. Nuovo tentativo ... ", eternamente ...: Quindi, dopo aver letto molto, ho riavviato il mio sistema e ho guardato il mio BIOS (F2 per ottenere lì, su PC) e la virtualizzazione era disabilitata . L'ho abilitato, salvato e riavviato il sistema, per verificare se è cambiato qualcosa.

Dopo ciò, ha vagrant upfunzionato come un fascino! Sono le 4 del mattino ma è in esecuzione! Che bello, hã? : D Come so che ci sono pochissimi sviluppatori masochisti come me, che proverebbero questo su Windows, specialmente su Windows 10 , non potevo non dimenticare di venire qui e lasciare la mia parola ... Un'altra informazione importante, è che, Stavo cercando di configurare Laravel 5 , usando Homestead, VirtualBox, compositore ecc. Ha funzionato. Quindi, spero che questa risposta aiuti come questa domanda e le risposte mi hanno aiutato. I miei migliori auguri. G-bye!

Stavo testando una cartella montata nella mia macchina virtuale vagabonda aggiungendo una nuova voce in /etc/fstab. Più tardi mi sono disconnesso, ho eseguito l'arresto vagabondo, ma quando ho corso vagrant upho ottenuto:

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

Ho letto tutti questi post e ho provato tutti quelli che sembravano rilevanti per il mio caso (tranne per la distruzione del vagabondo, che avrebbe sicuramente risolto il mio problema, ma era l'ultima risorsa nel mio caso). Il post di @Kiee mi ha dato l'idea di provare ad avviare la mia VM direttamente dalla GUI di VirtualBox. Durante il processo di avvio, la VM si è fermata e mi ha chiesto se volevo saltare il montaggio della cartella di test che avevo aggiunto in precedenza /etc/fstab. (Ecco perché vagrant non è riuscito ad avviare la VM.) Dopo aver risposto 'NO' la VM non ha avviato alcun problema. Ho effettuato l'accesso, rimosso la linea impertinente dal mio fstab e arrestato la VM.

Dopo quel vagabondo è stato in grado di avviarsi bene.

Porta via? Se all'improvviso un vagabondo non riesce a riavviarsi nella VM, provare ad avviare direttamente dal provider (VirtualBox nel mio caso). È probabile che il tuo stivale sia sospeso per qualcosa di totalmente estraneo a SSH.

Ho avuto lo stesso problema quando stavo usando x64 box (chef / ubuntu-14.04).

Ho cambiato in x32 e ha funzionato (hashicorp / precise32).

Forse questa è una risposta troppo semplice per aiutare molte persone, ma vale la pena provare se non lo hai fatto: fai un "arresto vagabondo" invece di una "sospensione vagabonda", quindi riavvia la VM con "vagabondaggio su".

Penso che il mio problema fosse dovuto a un processo "kworker" che si rompeva e si spegneva costantemente nella VM e quindi fare un riavvio difficile sembrava ricaricare correttamente il processo mentre un salvataggio e un ripristino stavano semplicemente ripristinando il processo interrotto nel suo stato interrotto.

Ho ottenuto questo durante l'esecuzione di Vagrant / VirtualBox all'interno di VirtualBox. Ho risolto questo problema eseguendo la macchina vagabonda nella macchina host.

Ho scoperto che su MacOS con VirtualBox l'aggiunta di questo a Vagrantfile ti consentirà di andare oltre:

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

L'installazione di un bit Ubuntu32 su un bit AMD64 ha funzionato. Non ho accesso ai BIO dal momento che è un ambiente limitato, ma ero ancora in grado di farlo funzionare con Ubuntu / Trusty32 invece di Ubuntu / Trusty64

Utilizzo di Vagrant 1.6.3 con VirtualBox 4.3.15 su Windows 7 SP1

spero che aiuti.

Per me è stata la compatibilità tra vagabondo e scatola virtuale.

Sono su Windows 10 e quello che ho fatto ho disinstallato Vagrant e Virtual Box

Quindi installa una vecchia versione della scatola virtuale in particolare la versione 4.3.38 (Installa il pacchetto di estensione anche per questa versione)

Quindi ha installato l'ultima copia di Vagrant (1.8.5 al momento)

Dopodiché ha funzionato.

Se non si desidera abilitare la GUI e successivamente è necessario disabilitarla, è possibile installare anche il pacchetto di estensione da Oracle:

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

Quindi inseriscilo nel tuo Vagrantfile per abilitare VRDP:

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

Ora è possibile utilizzare RDP per connettersi al proprio box su richiesta senza che SSH debba essere in esecuzione o la GUI aperta tutto il tempo.

Un'altra soluzione possibile per gli utenti del provider VMware: per me il problema è stato risolto dopo aver rimosso un'installazione parallela di VirtualBox sullo stesso computer host. Le interfacce di rete tra VMware e VirtualBox erano apparentemente in conflitto

Ho affrontato lo stesso problema. Ho risolto questo abilitando Virtualizationdall'installazione BIOS.

Elimina il file:

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

Quindi eseguire:

vagrant up

Ciò che ha funzionato per me è stato consentire la virtualizzazione a 64 bit su un sistema operativo a 64 bit (Ubuntu 13.10) dal BIOS.

Verifica che la virtualizzazione della CPU nella configurazione del BIOS sia abilitata.

Nel mio caso, assegnandogli un indirizzo IP statico, ho semplicemente risolto il problema:

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

FWIW-- Il mio problema era dovuto all'uso di un file di configurazione molto vecchio invece di uno più recente. L'uso del nuovo file di configurazione (e quindi ottimizzato / modificato DSL) ha risolto immediatamente i miei problemi.

Ciò che mi ha aiutato è stato l'abilitazione della virtualizzazione nel BIOS, perché la macchina non si è avviata.

Piuttosto che ctrl-d-out dalla scatola virtuale come non farò ogni volta che mi immergerò in qualcosa, credo che Vagrant preferirebbe che tu entrassi in un altro terminale e facessi un:

vagrant halt

per fermare la scatola. Quindi non ci saranno problemi a tornare nel VB.