Vagabundo atascado en el tiempo de espera de la conexión reintentando

Mi vagabundo estaba trabajando perfectamente bien anoche. Acabo de encender la PC, golpeo vagrant up, y esto es lo que obtengo:

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

¿Alguien ha tenido esto antes? vagabundo aún no está ampliamente cubierto en la web y no puedo encontrar una razón por la cual esto está ocurriendo.

Resolví este problema y responderé en caso de que alguien más tenga un problema similar.

Lo que hice fue: habilité la GUI de Virtual box para ver que estaba esperando la entrada en el inicio para seleccionar si quería arrancar directamente a ubuntu o safemode, etc.

Para activar la GUI, debe poner esto en su configuración vagabunda Vagrantfile:

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

Cuando está atascado con su máquina vagabunda de la manera descrita anteriormente, no es necesario iniciar en modo gui (y es imposible sin un servidor X).

Mientras su VM se inicia, en una ventana de terminal separada, solo descubra la identificación de la máquina en ejecución.

vboxmanage list runningvms

Esto resultará en algo como esto:

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

Muy a menudo, la VM simplemente está esperando que seleccione una opción en el gestor de arranque. Puede enviar el código clave apropiado (en el caso Enter) a la máquina virtual con controlvm:

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

Eso es. Su máquina virtual continuará el proceso de arranque.

Una cosa que debe verificar es si la virtualización de hardware está habilitada en el BIOS de su máquina.

Mi problema es la misma cadena de tiempos de espera, pero solo pude ver una pantalla en negro en la GUI.

Una computadora portátil que estaba configurando seguía mostrando el mismo problema. Después de horas de búsqueda, finalmente encontré un consejo para ver si el BIOS tenía habilitada la virtualización de hardware.

Aquí está el contenido de la publicación que encontré:

Veo que todavía hay algunos usuarios que están experimentando este problema. Por lo tanto, intentaré resumir una lista a continuación de algunas posibles soluciones al problema de tiempo de espera de SSH:

• Asegúrese de que su firewall o antivirus no esté bloqueando el programa (lo cual dudo que suceda con frecuencia)
• Dele a su máquina vagabunda un poco de tiempo para que ocurran los tiempos de espera. Si no tiene una PC / Mac muy rápida, la VM tardará un tiempo en iniciarse en un estado preparado para SSH, por lo que se producirán tiempos de espera.
• Por lo tanto, primero trate de dejar que el tiempo de espera vagabundo COMPLETAMENTE antes de concluir que hay una falla.
• Si vagabundo agota el tiempo de espera por completo, aumente el límite de tiempo de espera en el archivo vagabundo a unos minutos e intente nuevamente.
• Si eso aún no funciona, intente limpiar el arranque de su máquina vagabunda a través de la interfaz VirtualBox y habilite la GUI de la máquina de antemano. Si la GUI no muestra que ocurra nada (es decir, solo pantalla negra, sin texto) mientras se inicia, entonces su máquina vagabunda tiene problemas.
• Destruya toda la máquina a través de la interfaz VB y vuelva a instalarla.
• Elimine los archivos de imagen de ubuntu en la carpeta Vagrant Images en la carpeta de usuario y vuelva a descargar e instalar.
• ¿Incluso tiene un procesador Intel que admita la virtualización de hardware de 64 bits? Buscalo en Google. Si lo hace, asegúrese de que no haya ninguna configuración en su BIOS que deshabilite esta función.
• Deshabilite la función Hyper-V si está ejecutando Windows 7 u 8. Google cómo deshabilitar.
• Asegúrese de estar ejecutando a través de un cliente habilitado para SSH. Usa Git bash. Descargar: http://git-scm.com/downloads
• Instale una versión de 32 bits de ubuntu como trusty32 o precisa32. Simplemente cambie la versión en el archivo vagabundo y vuelva a instalar vagabundo en el nuevo directorio.
• Asegúrese de estar utilizando las últimas versiones de vagrant y virtualbox. Últimos recursos: formatee su computadora, reinstale Windows y compre un procesador Intel Core Isomething.

Espero que ayude.

La solución que he encontrado es verificar la opción de conexión de cable en el adaptador 1 que está conectado a NAT. Realmente no lo sé, esta es mi cuarta caja vagabunda, pero esta es la única con la opción de conexión de cable no marcada, y al verificarla, funciona.

Tuve exactamente el mismo problema. Pensé que el problema podría ser con las claves SSH (localización incorrecta del archivo u otra cosa, pero lo revisé muchas veces) pero siempre puede agregar en la sección de configuración nombre de usuario y contraseña (sin usar las teclas ssh) y ejecutar gui para que el código Vagrantfilese vea como más o menos como a continuación:

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

En mi caso, incluso si se mostraba GUI, recibí una pantalla negra (sin errores o posibilidad de iniciar sesión o cualquier otra cosa) y en la consola obtuve el Error: Connection timeout. Retrying... muchas veces. Me aseguré de tener VT-x (virtualización) habilitado en BIOS, verifiqué muchas combinaciones de versiones de Virtual Box y Vagrant juntas y muchas cajas Vagrant (para algunas de ellas no tenía pantalla negra en la GUI pero aún tenía conexión problemas). Finalmente, actualicé VirtualBox y Vagrant nuevamente a las últimas versiones y el problema aún ocurrió.

Lo crucial fue mirar los íconos en VirtualBox después de ejecutar vagrantup (con la GUI Vagrantfilecomo se muestra arriba) como en la imagen de abajo

Aunque no tuve errores en VirtualPC (sin advertencias de que VT-x no está habilitado) mi Vícono estaba en gris anterior, por lo que significa que VT-x estaba deshabilitado. Como dije, lo tenía habilitado en mi BIOS todo el tiempo.

Finalmente me di cuenta del problema por el HYPER-Vcual también instalé y habilité para probar sitios en Internet Explorer anterior. Fui a Windows Control Panel -> Programs and functions / Softwarey elegí del menú de la izquierda Turn on or Turn off Windows functions(espero que los encuentres, utilizo Windows polaco, así que no sé los nombres exactos en inglés). Apagué Hyper-V, reinicié la PC y después de ejecutar Virtual Box y vagrant upfinalmente no tuve errores, en la GUI tengo una pantalla de inicio de sesión y mi Vícono dejó de estar en gris.

Perdí mucho tiempo resolviendo este problema (y muchos reinicios de PC), así que espero que esto pueda ser útil para cualquier persona que tenga problemas en Windows; asegúrese de tener Hyper-V apagado en su Panel de control.

La mía estaba funcionando bien y luego este "Advertencia: desconexión de la conexión remota. Volviendo a intentar ..." una y otra vez, tal vez 20 veces, hasta que se conectó. Basado en las respuestas anteriores, solo

vagrant destroy
vagrant up

y todo estuvo bien. La mía era muy simple, pero lo hice de esa manera cortando el Vagrantfile a solo el config.vm.box = "ubuntu/trusty64"y todavía lo estaba haciendo. Por eso, destruir y comenzar de nuevo parecía la mejor opción. Dada la naturaleza sin estado de estas imágenes vagabundas, no veo por qué eso no funcionaría en todos los casos. Me estoy metiendo en esto y todavía puedo aprender que eso no es cierto.

Experimenté el mismo problema en una máquina con Windows 8.1. El tiempo de espera de conexión y la habilitación de la interfaz gráfica de usuario no fue útil en absoluto, la pantalla era negra. La solución en mi caso fue deshabilitar "Hyper V"

Cita de la documentación de Vagrant https://docs.vagrantup.com/v2/hyperv/index.html

Advertencia: Habilitar Hyper-V hará que VirtualBox, VMware y cualquier otra tecnología de virtualización ya no funcione. Consulte esta publicación de blog https://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx para obtener una forma fácil de crear una entrada de arranque para arrancar Windows sin Hyper-V habilitado, si habrá ocasiones en que necesitará otros hipervisores.

Si está trabajando en Windows 8 o 10, esto es lo que funcionó para mí:

1. Cambie la configuración del BIOS para permitir la virtualización de 64 bits.
2. Aquí es cómo:
   • Reinicie la PC usando el Inicio avanzado (Vaya a Inicio avanzado -'reiniciar ahora '-' solucionar problemas '-'opción avanzada'-' Configuración de firmware UEFI '-' Reiniciar ')
   • Ventana interior del BIOS: vaya al menú / pestaña 'Avanzado': habilite 'Tecnología virtual Intel'
   • Guardar la salida.

Tuve un problema con esto con una caja existente (no estoy seguro de qué cambió), pero pude conectarme a través de SSH, aunque la caja Vagrant no pudo iniciarse. Como sucede, mi clave SSH había cambiado de alguna manera.

Ejecuté desde la carpeta raíz vagabunda vagrant ssh-configque me dijo dónde estaba el archivo de clave. Abrí esto con puttygen y luego me dio una nueva clave.

En mi invitado Linux, edité ~/.ssh/authorized_keysy solté la nueva clave pública allí.

Todo vuelve a funcionar, ¡por ahora!

Tuve el mismo problema después de eliminar esta línea de mi Vagrantfile:

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

VM cargó bien después de volver a poner esta línea.

El tiempo de espera de la conexión SSH durante el arranque inicial puede estar relacionado con una variedad de razones, tales como:

• compruebe si la virtualización está habilitada en el BIOS (según el comentario ),
• el sistema espera la interacción del usuario (por ejemplo, la partición compartida no está lista ),
• desajuste de su clave privada (verifique la configuración a través de vagrant ssh-config),
• el proceso de arranque lleva mucho más tiempo (intenta aumentar config.vm.boot_timeout),
• se inicia desde la unidad incorrecta (por ejemplo, desde el instalador ISO),
• iptablesConfiguración incorrecta del cortafuegos VM (por ejemplo, configuración ),
• reglas de firewall local, conflicto de puerto o conflicto con un software VPN,
• sshd mala configuración

Para depurar el problema, ejecute una --debugopción o como:

VAGRANT_LOG=debug vagrant up

Si no hay nada obvio, intente conectarse desde otro terminal, por vagrant ssho por:

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

Si el SSH aún falla, intente ejecutarlo con una GUI (por ejemplo config.gui = true).

Si no es así, verifique los procesos en ejecución (por ejemplo, por vagrant ssh -c 'pstree -a':) o verifique su sshd_config.

Si es una máquina virtual desechable, siempre puede intentarlo destroyy upnuevamente.

También debe considerar actualizar su Vagrant y Virtualbox.

Para obtener más información, consulte la página Depuración y solución de problemas .

Tuve el mismo problema, pero ninguna de las otras respuestas resolvió por completo mi problema. La respuesta de @Kiee fue útil, aunque todo lo que pude ver en la GUI fue una pantalla en negro (con un guión bajo en la parte superior izquierda, este problema en Virtual Box también se ha planteado por separado en el desbordamiento de la pila, de nuevo, nada ayudó).

Finalmente, una solución resultó ser muy simple: verifique la versión de su máquina virtual.

Más precisamente, recibí una caja de otra persona con Debian de 64 bits, pero Virtual Box insistió en tratarla como 32 bits, lo que no noté. Para cambiarlo, abra Virtual Box, luego abra la terminal y ejecute

vagrant up

espera la cola

default: SSH auth method: private key

ahora puede presionar ctrl + C (o esperar el tiempo de espera) y ejecutar

vagrant halt

su máquina virtual no se destruirá, por lo que puede verla en el menú de Virtual Box, pero se apagará, para que pueda cambiar la configuración. Elija su máquina en el menú, haga clic en 'Configuración' -> 'General' y elija la 'Versión' adecuada, para mí fue 'Debian (64 bits)'. Después de este tipovagrant up nuevo.

Si este es un caso para usted (o los diferentes cambios en 'Configuración' resolvieron su problema), puede crear un nuevo cuadro desde el reparado escribiendo

vagrant package --output mynew.box

Algunos detalles más: host Ubuntu 12.04 de 32 bits, Debian 8.1 de 64 bits invitado, Virtual Box 5.0.14, Vagrant 1.8.1

Aquí hay muchas buenas respuestas, y no pude leerlas todas, pero también vine a dar mi pequeña contribución. Tuve 2 problemas diferentes:

1. vagrant upno pude encontrar mi ssh ' id_rsa ' (porque aún no lo tenía, en ese momento): corrí ssh-keygen -t rsa -b 4096 -C "[email protected]", basado en este artículo de GitHub , y voilá, lo supere;

2. Entonces, tuve el mismo problema de esta pregunta " Advertencia: se agotó el tiempo de espera de la conexión. Reintentando ... ", eternamente ...: Entonces, después de leer mucho, reinicié mi sistema y miré mi BIOS (F2 para obtener allí, en la PC), y había Virtualización deshabilitada . Lo habilité, guardé e inicié el sistema una vez más, para verificar si ha cambiado algo.

Después de eso, vagrant upfuncionó como un encanto! ¡Son las 4 de la mañana pero está funcionando! Que guay, hã? : D Como sé que hay muy pocos desarrolladores masoquistas como yo, que intentarían esto en Windows, especialmente en Windows 10 , simplemente no podía olvidar olvidar venir aquí y dejar mi palabra ... otra información importante, es que, Estaba tratando de configurar Laravel 5 , usando Homestead, VirtualBox, compositor, etc. Funcionó. Entonces, espero que esta respuesta ayude como esta pregunta y las respuestas me ayudaron. Mis mejores deseos. Adios

Estaba probando una carpeta montada en mi VM vagabundo agregando una nueva entrada en /etc/fstab. Más tarde me desconecté, ejecuté un alto vagabundo, pero cuando corrí vagrant upobtuve:

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

Leí todas estas publicaciones y probé todas las que parecían relevantes para mi caso (a excepción de la destrucción vagabunda, que sin duda habría solucionado mi problema, pero era un último recurso en mi caso). La publicación de @Kiee me dio la idea de intentar iniciar mi VM directamente desde la GUI de VirtualBox. Durante el proceso de arranque, la máquina virtual se detuvo y me preguntó si quería omitir el montaje de la carpeta de prueba que había agregado anteriormente /etc/fstab. (Es por eso que vagabundo no pudo arrancar la VM). Después de responder 'NO', la VM arrancó sin problema. Inicié sesión, eliminé la línea traviesa de mi fstab y apagué la máquina virtual.

Después de que el vagabundo pudo arrancar bien.

¿Para llevar? Si de repente un vagabundo no puede reiniciar en su VM, intente iniciar directamente desde el proveedor (VirtualBox en mi caso). Lo más probable es que su arranque esté colgando por algo totalmente ajeno a SSH.

Tuve el mismo problema cuando estaba usando x64 box (chef / ubuntu-14.04).

Cambié a x32 y funcionó (hashicorp / precise32).

Tal vez esta sea una respuesta demasiado simple para ayudar a muchas personas, pero vale la pena intentarlo si no lo ha hecho: haga un "alto vagabundo" en lugar de una "suspensión vagabunda" y luego reinicie la VM con "vagabundo".

Creo que mi problema se debió a que algunos procesos "kworker" se volvían defectuosos y constantemente caducaban en la máquina virtual, por lo que hacer un reinicio forzado parecía volver a cargar el proceso correctamente, mientras que guardar y restaurar solo restauraba el proceso roto en su estado roto.

Obtuve esto cuando ejecuto vagrant / VirtualBox dentro de VirtualBox. Resolví esto ejecutando la máquina vagabunda en la máquina host.

Descubrí que en MacOS con VirtualBox agregar esto a Vagrantfile te permitirá ir más allá:

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

Instalar un ubuntu32 bits en un AMD64 bits hizo el truco. No tengo acceso a los BIO ya que es un entorno restringido, pero aún así pude hacer que funcionara con ubuntu / trusty32 en lugar de ubuntu / trusty64

Uso de Vagrant 1.6.3 con VirtualBox 4.3.15 en Windows 7 SP1

Espero que ayude.

Para mí fue la compatibilidad entre vagabundo y virtual box.

Estoy en Windows 10 y lo que hice desinstalé la caja virtual y vagabunda

Luego instale una versión anterior de Virtual Box específicamente la versión 4.3.38 (Instale el paquete de extensión también para esta versión)

Luego instaló la última copia de vagabundo (1.8.5 en este momento)

Después de eso funcionó.

Si no desea habilitar la GUI y luego tiene que deshabilitarla más tarde, también puede instalar el paquete de extensión desde Oracle:

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

Luego ponga esto en su Vagrantfile para habilitar VRDP:

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

Ahora puede usar RDP para conectarse a su caja bajo demanda sin necesidad de ejecutar SSH o abrir la GUI todo el tiempo.

Una posible solución más para los usuarios del proveedor de VMware: para mí, el problema se resolvió después de eliminar una instalación paralela de VirtualBox en la misma máquina host. Las interfaces de red entre VMware y VirtualBox aparentemente estaban en conflicto

Me he enfrentado al mismo problema. Lo arreglé habilitando Virtualizationdesde la BIOSconfiguración.

Eliminar el archivo:

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

Entonces corre:

vagrant up

Lo que funcionó para mí fue permitir la virtualización de 64 bits en un sistema operativo de 64 bits (Ubuntu 13.10) desde BIOS.

Verifique que la virtualización de su CPU en la configuración del BIOS esté habilitada.

En mi caso, darle una dirección IP estática, simplemente resolvió el problema:

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

FWIW: mi problema se debió al uso de un archivo de configuración muy antiguo en lugar de uno nuevo. Usar el nuevo archivo de configuración (y, por lo tanto, ajustar / cambiar DSL) solucionó mis problemas al instante.

Lo que me ayudó fue habilitar la virtualización en BIOS, porque la máquina no arrancaba.

En lugar de hacer ctrl-d-out de la caja virtual como lo hago habitualmente cada vez que me meto en algo, creo que vagabundo preferiría que entres en otra terminal y hagas un:

vagrant halt

para detener la caja Entonces no habrá problemas para volver al VB.