Vagrant coincé délai d'attente de connexion de réessayer

lorsque vous êtes bloqué avec votre machine errante de la façon décrite ci-dessus, il n'est pas nécessaire de démarrer en mode gui (et c'est impossible sans serveur X).

pendant que votre VM démarre, dans une fenêtre de terminal séparée, découvrez simplement l'id de la machine en cours d'exécution.

vboxmanage list runningvms

il en résultera quelque chose comme ceci:

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

très souvent, la VM attend simplement que vous sélectionniez une option dans la bootloader. Vous pouvez envoyer le code approprié (dans le cas, entrer ) à la vm avec controlvm :

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

C'est ça. Votre machine virtuelle va continuer le processus de démarrage.

une chose à vérifier est si la Virtualisation matérielle est activée dans le BIOS de votre machine.

mon problème est la même chaîne de timeouts mais je ne pouvais voir qu'un écran noir dans l'interface graphique.

un ordinateur portable que je mettais en place montrait le même problème. Après des heures de recherche, j'ai enfin trouvé un truc pour voir si le BIOS avait une Virtualisation matérielle activée.

Voici le contenu du post que j'ai trouvé:

je vois qu'il y a encore des utilisateurs qui éprouvent ce problème. Ainsi, je vais essayer de résumer une liste ci-dessous de quelques solutions possibles au problème de délai SSH:

• assurez-vous que votre pare-feu ou l'antivirus ne bloque pas le programme (ce qui je doute arrivera souvent)
• donnez à votre machine vagabonde Un peu de temps pour que des temps morts se produisent. Si vous n'avez pas un PC / Mac très rapide, la VM prendra du temps pour démarrer dans un État SSH prêt, donc des temps morts vont arriver.
• par conséquent, d'abord essayer de laisser vagrant délai complètement avant de conclure qu'il ya une faute.
• si vagrant sort complètement, augmentez la limite de temps dans le fichier vagrant à quelques minutes et réessayez.
• si cela ne fonctionne toujours pas, essayez de nettoyer votre machine vagabonde à travers L'interface VirtualBox et activez l'interface graphique de la machine à l'avance. Si L'interface graphique ne pas montrer tout ce qui se passe (c'est à dire. juste un écran noir, Pas de texte) pendant qu'il démarre, alors votre machine vagabonde a des problèmes.
• détruisez la machine entière à travers l'interface VB et réinstallez.
• supprimer les fichiers image ubuntu dans le dossier Vagrant Images dans le dossier de l'utilisateur et télécharger à nouveau et installer.
• avez-vous même un processeur intel qui prend en charge la virtualisation matérielle 64bit? Une recherche sur Google. Si vous le faites, assurez-vous il n'y a aucun paramètre dans votre Bios désactivant cette fonctionnalité.
• désactivez la fonctionnalité hyper-v si vous utilisez windows 7 ou 8. Google comment désactiver.
• assurez-vous que vous utilisez un client compatible ssh. L'utilisation de Git bash. Télécharger: http://git-scm.com/downloads
• installez une version 32bit d'ubuntu comme trusty32 ou precise32. Il suffit de modifier la version dans le fichier vagrant et de réinstaller vagrant dans le nouveau répertoire.
• assurez-vous que vous utilisez les dernières versions vagrant et virtualbox. Last resorts: formatez votre ordinateur, réinstallez windows et achetez un processeur intel core isomething.

Espère que ça aide.

la solution que j'ai trouvée est de vérifier l'option de connexion par câble dans l'Adaptateur 1 qui est attaché au NAT. Je ne sais vraiment pas, c'est ma 4ème BOITE vagabonde mais c'est la seule avec l'option de connexion par câble non cochée, et en la vérifiant, ça marche.

j'ai eu exactement le même problème. J'ai pensé que le problème pourrait être avec les clés SSH (mauvaise localisation du fichier ou quelque chose d'autre mais je l'ai vérifié de nombreuses fois) mais vous pouvez toujours ajouter dans la section Configurer le nom d'utilisateur et le mot de passe (sans utiliser les clés ssh) et l'exécution de gui donc le code dans Vagrantfile devrait ressembler plus ou moins comme ci-dessous:

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

dans mon cas, même si GUI était affiché j'ai eu l'écran noir (aucune erreur ou possibilité de se connecter ou autre chose) et dans la console j'ai eu le Error: Connection timeout. Retrying... plusieurs fois. Je me suis assuré que J'avais VT-x (virtualisation) activé dans le BIOS, j'ai vérifié de nombreuses combinaisons de versions de Virtual Box et Vagrant ainsi que de nombreuses boîtes Vagrant (pour certaines d'entre elles, je n'avais pas d'écran noir dans GUI mais j'avais encore des problèmes de connexion). Enfin, J'ai mis à jour VirtualBox et Vagrant à nouveau aux dernières versions et le problème s'est toujours produit.

l'essentiel était de regarder les icônes dans VirtualBox après avoir lancé vagrantup (avec GUI dans Vagrantfile comme je l'ai montré ci-dessus) comme sur l'image ci-dessous

bien que je N'ai eu aucune erreur dans VirtualPC (aucun avertissement que VT-x n'est pas activé) mon icône V était gris plus tôt donc cela signifie que le VT-x a été désactivé. Comme je l'ai dit, Je l'avais activé dans mon BIOS tout le temps.

finalement j'ai réalisé le problème pourrait par HYPER-V que j'ai également installé et permis de tester sites sur Internet Explorer plus ancien. Je suis allé sur Windows Control Panel -> Programs and functions / Software et j'ai choisi dans le menu à gauche Turn on or Turn off Windows functions (j'espère que vous trouverez ces derniers, J'utilise Windows polonais donc ne sais pas les noms exacts en anglais). J'ai désactivé Hyper-V, redémarré le PC et après avoir lancé Virtual Box et vagrant up Je n'ai finalement eu aucune erreur, dans GUI j'ai l'écran de connexion et mon icône V arrêtée pour être grise.

j'ai perdu beaucoup de temps à résoudre ce problème (et de nombreux PC redémarre) donc j'espère que cela peut être utile à tous ceux qui ont des problèmes sur Windows - assurez-vous que vous avez Hyper-V éteint dans votre Panneau de contrôle.

la Mine fonctionnait très bien et puis cet " avertissement: déconnexion de la connexion à distance. Réessayer..."- peut-être 20 fois jusqu'à ce qu'il connecté. Sur la base des réponses ci-dessus je juste

vagrant destroy
vagrant up

et tout était bon. Le mien était très simple mais je l'ai fait de cette façon en coupant le Vagrantfile à juste le config.vm.box = "ubuntu/trusty64" et il le faisait toujours. C'est pourquoi la détruire et recommencer semblait le meilleur choix. Étant donné le caractère apatride de ces vagabonds images Je ne vois pas pourquoi ça ne marcherait pas dans tous les cas. Je suis juste à entrer dans ce et j'ai peut encore apprendre que ce n'est pas vrai.

j'ai éprouvé le même problème sur une machine Windows 8.1. Le délai de connexion et l'activation de l'interface graphique n'étaient pas du tout utiles, l'écran était noir. La solution dans mon cas était de désactiver "Hyper V "

citation tirée de la documentation sur les vagabonds https://docs.vagrantup.com/v2/hyperv/index.html

avertissement: si vous activez Hyper-V, VirtualBox, VMware et toute autre technologie de virtualisation ne fonctionneront plus. Voir ce billet de blog https://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx pour un moyen facile de créer une entrée de démarrage pour démarrer Windows sans Hyper-V activé, s'il y aura des fois, vous aurez besoin d'autres hyperviseurs.

Si vous travaillez sur Windows 8 ou 10, c'est ce qui a fonctionné pour moi:

1. modifiez les paramètres du BIOS pour permettre la virtualisation de 64bit.
2. Voici comment:
   • redémarrez PC en utilisant le démarrage avancé (passez à Démarrage Avancé -'redémarrez maintenant'-'dépannage' -'option avancée'- 'Paramétrage du micrologiciel UEFI' - 'redémarrez')
   • dans la fenêtre du BIOS-allez à' Advanced 'menu / tab-Enable 'Intel Virtual Technology'
   • Save & Exit.

j'ai eu un problème avec cela avec une boîte existante (pas sûr de ce qui a changé), mais je pourrait se connecter via SSH, même si la boîte vagabonde n'a pas réussi à démarrer. Il se trouve que ma clé SSH avait changé d'une façon ou d'une autre.

du dossier racine errant j'ai lancé vagrant ssh-config qui m'a dit Où était le fichier clé. J'ai ouvert ça avec puttygen et puis il m'a donné une nouvelle clé.

sur mon invité Linux, j'ai édité ~/.ssh/authorized_keys et abandonné la nouvelle clé publique.

Tout fonctionne à nouveau - pour l'instant!

j'ai eu le même problème après que j'ai supprimé cette ligne de mon Vagrantfile:

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

VM chargé amende après que j'ai remis cette ligne.

j'ai eu le même problème, mais aucune des autres réponses entièrement résolu mon problème. La réponse de @Kiee a été utile, bien que tout ce que j'ai pu voir dans le GUI était un écran noir (avec souligné en haut à gauche, cette question dans la boîte virtuelle a également été soulevée séparément dans le débordement de la pile, encore une fois rien n'a aidé).

finalement, une solution s'est avérée très simple: check version de votre machine virtuelle.

Plus précisément, J'avais une boîte de Quelqu'un d'autre avec Debian 64 bits, mais Virtual Box a insisté pour la traiter comme 32 bits, ce que je n'ai pas remarqué. Pour le changer, ouvrez la boîte virtuelle, puis ouvrez le terminal et lancez

vagrant up

attendre pour la ligne

default: SSH auth method: private key

maintenant vous pouvez appuyer sur ctrl+C (ou attendre le temps d'arrêt) et exécuter

vagrant halt

votre machine virtuelle ne sera pas détruite, donc vous pouvez la voir dans le menu de la boîte virtuelle, mais sera alimentée off, de sorte que vous pouvez changer les paramètres. Choisissez votre machine dans le menu, cliquez sur "Paramètres" -> "Général" et choisissez la bonne "Version", pour moi C'était " Debian (64-bit)". Après ce type vagrant up encore.

S'il s'agit d'un cas pour vous (ou différents changements dans les "paramètres" résolu votre problème), vous pouvez créer une nouvelle boîte à partir de la réparation tapez

vagrant package --output mynew.box

quelques détails supplémentaires: Ubuntu 32 bits 12.04, Debian 8.1 64 bits invité, Virtual Box 5.0.14, Vagrant 1.8.1

il y a beaucoup de bonnes réponses ici, et je ne pouvais pas tout lire, mais, je suis juste venu pour donner ma petite contribution aussi. J'ai eu deux problèmes différents:

1. vagrant up n'a pas pu trouver mon ssh ' id_rsa ' (parce que je ne l'avais pas encore, à ce moment-là): J'ai couru ssh-keygen -t rsa -b 4096 -C "myemailaddress@mydomain.com" , basé sur l'article de ce GitHub , et voilà, steped par cela;

2. puis, j'ai eu le même problème de cette question " avertissement: connexion chronométrée. Réessayer... ", éternellement...: Donc, après avoir beaucoup lu, j'ai redémarré mon système et j'ai regardé mon BIOS (F2 pour y arriver, sur PC), et il y avait virtualisation désactivée . J'ai activé cela, j'ai sauvegardé, et j'ai redémarré le système, pour vérifier s'il a changé quelque chose.

après cela, vagrant up travaillé comme un charme! Il est 4 heures du matin mais il court! Cool comment, hã? : D Comme je le sais, il y a très peu de développeurs masochistes comme moi, qui essayeraient cela à Windows , en particulier à Windows 10 , Je ne pouvais pas ne pas oublier de venir ici et laissé ma parole... une autre information importante, est que, j'ai essayé de mettre en place Laravel 5 , en utilisant Homestead, VirtualBox, compositeur, etc. Il a travaillé. Donc, j'espère que cette réponse aide comme cette question et les réponses m'ont aidé. De mon mieux souhaiter. G-bye!

le temps d'arrêt de la connexion SSH lors du démarrage initial peut être lié à diverses raisons telles que:

• vérifier si la virtualisation est activée dans le BIOS (selon commentaire ),
• le système attend l'interaction de l'utilisateur (par exemple la partition de partage n'est pas prête ),
• inadéquation de votre clé privée (vérifiez la configuration via vagrant ssh-config ),
• le processus de démarrage prend beaucoup plus de temps (essayez d'augmenter config.vm.boot_timeout ),
• il démarre à partir du mauvais lecteur (par exemple à partir de L'installateur ISO),
• pare-feu VM configuration incorrecte (par exemple, iptables configuration ),
• règles locales de pare-feu, conflit de ports ou conflit avec un logiciel VPN,
• sshd mauvaise configuration.

pour déboguer le problème, s'il vous plaît exécuter une --debug option ou comme:

VAGRANT_LOG=debug vagrant up

s'il n'y a rien d'évident, essayez de vous connecter à partir d'un autre terminal, par vagrant ssh ou par:

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

si le SSH échoue toujours, essayez de l'exécuter avec a GUI (e.g. config.gui = true ).

si ce n'est pas le cas, vérifiez les processus en cours d'exécution (par exemple: vagrant ssh -c 'pstree -a' ) ou vérifiez votre sshd_config .

si C'est VM jetable, vous pouvez toujours essayer de destroy it et up it à nouveau.

vous devriez également envisager de mettre à jour votre Vagrant et Virtualbox.

pour plus d'informations, consultez la page Débogage et dépannage .

je testais un dossier monté dans ma VM vagabonde en ajoutant une nouvelle entrée dans /etc/fstab . Plus tard, je me suis déconnecté, couru les arrêter, mais quand j'ai couru vagrant up j'ai eu:

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

j'ai lu tous ces messages et essayé tous ceux qui semblaient pertinents pour mon cas (sauf pour les détruire, ce qui aurait certainement corrigé mon problème, mais c'était un dernier recours dans mon cas). Le post de @Kiee m'a donné l'idée d'essayer de démarrer ma VM directement à partir de la VirtualBox GUI. Pendant le processus de démarrage, la VM s'est arrêtée et m'a demandé si je voulais sauter le montage du dossier test que j'avais ajouté plus tôt à /etc/fstab . (C'est pourquoi vagrant n'a pas pu démarrer la VM.) Après avoir répondu "non", la VM a démarré sans problème. Je me suis connecté, j'ai enlevé la ligne naughty de mon fstab, et j'ai éteint la VM.

après que ce vagabond ait pu démarrer très bien.

à emporter? Si tout d'un coup, vagabond ne peut pas démarrer votre machine virtuelle, essayez de démarrez directement depuis le fournisseur (VirtualBox dans mon cas). Il y a des Chances que votre botte soit suspendue pour quelque chose qui n'a aucun rapport avec SSH.

j'ai eu le même problème lorsque j'ai été en utilisant x64 boîte(chef/ubuntu-14.04).

j'ai changé pour x32 et ça a marché(hashicorp/precise32).

peut-être que c'est une réponse trop simple pour aider beaucoup de gens, mais qui vaut la peine d'essayer si vous ne l'avez pas fait: faites une "halte vagabonde" au lieu d'une "suspension vagabonde" puis redémarrez la VM avec "vagrant up".

je pense que mon problème était dû au fait qu'un processus" kworker " devenait buggy et chronométrait constamment dans la VM et donc faire un redémarrage dur semblait recharger le processus correctement alors qu'un save and restore était juste en train de restaurer le processus cassé dans son état cassé.

j'ai eu ça quand j'ai lancé vagrant/VirtualBox à L'intérieur de VirtualBox. J'ai résolu ça en lançant la machine vagabonde dans la machine hôte.

installer un ubuntu32 bits sur un amd64 bits a fait l'affaire. Je n'ai pas accès au BIOs depuis son environnement restreint, mais j'ai quand même réussi à le faire fonctionner avec ubuntu / trusty32 au lieu de ubuntu / trusty64

utilisant Vagrant 1.6.3 avec VirtualBox 4.3.15 sur Windows 7 SP1

espère que ça aide.

pour moi, c'était la compatibilité entre le vagabond et la boîte virtuelle.

je suis sur windows 10 et de ce que j'ai fait, j'ai désinstallé l'errance et virtual box

installez ensuite une ancienne version de virtual box spécifiquement la version 4.3.38 (installez extension pack aussi pour cette version)

puis installé la dernière copie de vagrant (1.8.5 à l'heure actuelle )

après ça, ça a marché.

j'ai découvert que sur MacOS avec VirtualBox ajouter ceci à Vagrantfile vous permettra d'aller plus loin:

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

si vous ne voulez pas activer L'interface graphique et que vous devez ensuite la désactiver, vous pouvez aussi installer le pack d'extension D'Oracle:

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

alors mettez ceci dans votre fichier Vagrant pour activer VRDP:

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

Maintenant, vous pouvez utiliser RDP pour vous connecter à votre boîte à la demande sans que SSH ait besoin d'être en cours d'exécution ou L'interface graphique ouvert tous les temps.

une solution de plus pour les utilisateurs du fournisseur VMware: Pour moi, le problème a été résolu après la suppression d'une installation parallèle de VirtualBox sur la même machine hôte. Les interfaces réseau entre VMware et VirtualBox étaient apparemment contradictoires

j'ai fait face au même problème. J'ai corrigé cela en activant Virtualization à partir de BIOS setup.

supprimer le fichier:

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

puis exécuter:

vagrant up

ce qui a fonctionné pour moi était d'autoriser la virtualisation 64 bits sur un OS 64 bits (Ubuntu 13.10) à partir du BIOS.

vérifiez que la virtualisation de votre CPU dans la configuration du BIOS est activée.

FWIW-- mon problème était dû à l'utilisation d'un très vieux fichier de configuration au lieu d'un plus récent. En utilisant le nouveau fichier de configuration (et donc modifié/changé DSL) corrigé mes problèmes instantanément.

ce qui m'a aidé, c'est d'avoir activé la virtualisation dans le BIOS, parce que la machine n'a pas démarré.

plutôt que ctrl-d-ing hors de la boîte virtuelle comme je suis habitué à le faire chaque fois que je ssh dans n'importe quoi, je crois que vagrant préférerait que vous entrez dans un autre terminal et faire un:

vagrant halt

pour arrêter la boîte. Ensuite, il n'y aura pas de problèmes pour obtenir retour dans le VB.

j'ai fait face à la même question, mais aucune des solutions mentionnées travaillé pour moi! Je l'ai résolu en déclassant Vagrant à 1.6.2 et maintenant ça marche!