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

417

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.

Kiee
fuente
La situación podría deberse a que VirtualBox no pudo redirigir los puertos, a pesar de decir ' ==> predeterminado: reenvío de puertos ... predeterminado: 22 => 2222 (adaptador 1) ' Puede echar un vistazo a la descripción completa en mi pregunta aquí enlace . Todavía no tengo idea de cómo solucionar el error de redireccionamiento (puede echar un vistazo en el registro de VirtualBox.
WebComer
Tengo el mismo problema. El problema era que el servidor ssh no estaba instalado y habilitado en la máquina invitada.
melihovv
Tuve el mismo error al instalar ubuntu 16.04: el problema se solucionó actualizando virtual box a 5.1.x; consulte askubuntu.com/a/822974/151137
house9 el
@Kiee Compruebe también el antivirus y el firewall, detenga ambos por el momento y luego vaya :)
AmmyTech

Respuestas:

375

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
Kiee
fuente
17
@Huuuze, el problema era que la máquina virtual podría no apagarse correctamente, y cuando probé SSHing al día siguiente, la máquina quería que seleccionara en qué modo quería iniciar, pero a través de la línea de comandos no tenía idea hasta que encendí la interfaz gráfica de usuario que me permitió elegir el modo.
Kiee
77
Gracias. En mi caso, la VM estaba atascada en el gestor de arranque (grub) esperando la tecla ENTER. Estoy usando el predeterminado hashicorp/precise32. Comencé la máquina con GUI, luego ejecuté sudo grub-mkconfigese restablecimiento del /boot/grub/grub.cfgarchivo, y luego pude comentar la vb.gui=truelínea.
maggix
2
@TangibleDream Su archivo Vagrant, en el directorio que está (o debería estar) ejecutandovagrant up
Kiee
44
@jasa Si es un vm vagabundo, hay una buena posibilidad de que el nombre de usuario y la contraseña sean ambosvagrant
Kiee
77
La GUI me mostró el siguiente error: la aceleración de hardware VT-x / AMD-V no está disponible en su sistema. Su búsqueda de 64 bits no podrá detectar una CPU de 64 bits y no podrá arrancar
SKuijers
213

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.

harrie
fuente
22
@ParrisVarney: la mayoría de las veces, este bloqueo se debe a que el gestor de arranque espera que se seleccione una entrada. Esto se hace enviándole la tecla Intro, que puede hacer usando la GUI o usando vboxmanagela interfaz de línea de comando para VirtualBox. Entonces está "controlando" la VM y enviándole un "código de escaneo" para la tecla Intro (1C) usando el parámetro keyboardputscancode.
Kautiontape
1
Realmente no entendí lo que hace, pero funcionó. Así que gracias.
Lavixu
1
Este enfoque particular no funcionó para mí. El único cambio que noté es que la salida del mensaje cambió de forma predeterminada: Warning: Connection timeout. Retrying...a default: Warning: Remote connection disconnect. Retrying...después de ejecutarse vboxmanage controlvm dst_default_1407935479617_2464 keyboardputscancode 1c. Intentaremos el vb.gui = trueen su lugar.
Marius Butuc
44
vboxmanage en Windows se encuentra en C:\Progra~1\Oracle\VirtualBox\VBoxManage.exedicho dicho, el cambio de BIOS a continuación me ayudó a solucionar este problema
yingw
1
Esta respuesta es increíble, esto debería marcarse como una respuesta.
inquisitivo
47

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.

Japo Domingo
fuente
2
Segundo, "verifique que la virtualización de hardware esté habilitada". Estaba experimentando este problema exacto, y reiniciar el host y luego habilitar la virtualización en el BIOS resolvió el problema.
MrBooks
2
Acabo de ser golpeado por esto. Hyper-V fue la causa y la desinstalación lo solucionó. tyvm
ChrisAnnODell
1
Contra intuitivamente, en mi BIOS, tuve que deshabilitar la virtualización y habilitar VT-X. Intente alternar esta configuración en su BIOS.
Onshop
44

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. Conexión de cable NAT

Cedric
fuente
1
Estoy usando Homestead 1.0.1 y VirtualBox 5.0.28 y resolví el problema gracias a esta respuesta.
Pablo Ezequiel Leone
A través de la GUI pude ver que estaba esperando en una interfaz de red y esto resolvió el problema. Thank.s
nsc_feabhas
Esto solucionó la mina +1
Zac Grierson
Esto solucionó mi problema: Vagrant 1.9; Virtualbox 5.1; Laravel / Homestead 5.3
J. LaRosee
34

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

ingrese la descripción de la imagen aquí

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.

Marcin Nabiałek
fuente
1
Ese fue el problema! Virtualización activada en BIOS y deshabilitado HYPER-V dentro de Programas y funciones. Funcionó como encanto !!
Heroselohim
@Heroselohim Me alegra que te haya ayudado, tomó mucho tiempo resolverlo.
Marcin Nabiałek
1
La contraseña ssh explícita me ayuda cuando una carpeta con subcarpeta vagabundo de puntos reside en Dropbox o se comparte de otra manera entre máquinas con claves ssh potencialmente diferentes.
mlt
31

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.

HankCa
fuente
Buena solución si puede aprovisionar su vm. En mi caso, construir un vm es más complicado y tomará aún más tiempo.
user12121234
55
Sí, configuré un alias y otras cosas en mi VM, destruirlo no es realmente una gran respuesta
Batman
Bien, lo intenté muchas veces, ¡ vragant haltpero esto funciona perfectamente!
Med
Funcionó muy bien para mí, me enfrentaba tanto al problema de restablecimiento de la conexión de host local como a esto, y destruir y crear vagabundos nuevamente solucionó esos problemas.
shivgre
19

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.

kri
fuente
55
Esto funcionó para mí. Simplemente deshabilité Hyper-V en Programas y características.
stringo0
He probado todas las soluciones anteriores y solo esto funcionó para mí también.
Gilberto Albino
17

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.
Geshan
fuente
2
Lo mismo aquí en el portátil T440p
separado
Igual que aquí. En mi máquina significaba habilitar la virtualización Vt-x
Erez Cohen
¡Gracias! La virtualización fue deshabilitada en la configuración de mi BIOS. Anteriormente había usado vagabundo en la misma máquina, pero por alguna razón la configuración del BIOS cambió sin que yo lo supiera. Entonces verifique esta configuración primero.
Bahman. A
8

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!

Steve Browett
fuente
8

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.

Dmitrii Mikhailov
fuente
Estoy usando scotch box, todo lo que hice fue descomentar la línea config.vm.networky resolvió el problema.
Alexar
5

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 .

kenorb
fuente
4

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

Gwidryj
fuente
Tuve la misma situación, perdí un día por esto, también no tenía 64 bits en mi menú desplegable allí, así que revisé fixedbyvonnie.com/2014/11 / ... y lo resolví
Alex Sutu
4

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

giovannipds
fuente
4

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.

wmaddox
fuente
3

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

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

Andrii Furmanets
fuente
Su problema podría ser que está ejecutando Hyper-V, consulte la respuesta de @ Kri arriba, me encontré con problemas con un x64 en x64 porque estaba ejecutando Hyper-V
Ian M
3

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.

Ambulare
fuente
Guau. Al final. Esto funcionó para mí. Estoy usando la ventana 7. @Ambulare gracias!
Emeka Mbah
3

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

Jarzka
fuente
3

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
David
fuente
¡Esto funcionó para mí después de investigar este problema durante horas!
Sorin el
encantado de ayudar :)
David
2

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.

fracca
fuente
2

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

Jplus2
fuente
Tuve el mismo problema aquí. Virtualbox tenía una actualización disponible. Actualizando eso, y un comando "vagabundo destruir" y "vagabundo arriba" lo arreglaron.
mrBrown
1

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.

JustinParker
fuente
1

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

Hinnerk
fuente
1

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

Mahbub
fuente
1
Contra intuitivamente, en mi BIOS, tuve que desactivar la virtualización y activar VT-X. Intente alternar esta configuración en su BIOS.
Onshop
1

Eliminar el archivo:

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

Entonces corre:

vagrant up
pppery
fuente
He buscado en Internet durante tres días y probé casi todas las soluciones que encontré. Solo descubrirlo puede ser tan simple como esto. Mi héroe. ¡Gracias! +1
Robin van Baalen
no hace la diferencia para mí tengo mac, Vagrant 1.9.3
Razvan Tudorica
1

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.

Geshan
fuente
¡Probablemente estés hablando de virtualización de 64 bits!
WebComer
1

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

mcrunix
fuente
1

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

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

Alexar
fuente
0

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.

profesor
fuente
0

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

Bartłomiej Zalewski
fuente
Contra intuitivamente, en mi BIOS, tuve que desactivar la virtualización y activar VT-X. Intente alternar esta configuración en su BIOS.
Onshop
0

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.

rachel
fuente
1
ctrl+dcierra la sesión. No tiene nada de malo hacer eso, y no le hace nada a una máquina en funcionamiento. vagrant haltdetiene la máquina virtual.
Zoltán