Expiration du délai de connexion bloqué Vagrant

Mon vagabond fonctionnait parfaitement bien la nuit dernière. Je viens d'allumer le PC, de frapper vagrant up, et voici ce que j'obtiens:

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

Quelqu'un a-t-il déjà eu cela? vagrant n'est pas encore largement couvert sur le web et je ne trouve pas de raison pour laquelle cela se produit.

J'ai résolu ce problème et je répondrai au cas où quelqu'un d'autre aurait un problème similaire.

Ce que j'ai fait était: j'ai activé l'interface graphique de la boîte virtuelle pour voir qu'elle attendait une entrée au démarrage pour sélectionner si je voulais démarrer directement sur Ubuntu ou Safemode, etc.

Pour activer l'interface graphique, vous devez mettre cela dans votre configuration vagabonde Vagrantfile:

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

Lorsque vous êtes coincé avec votre machine vagabonde de la manière décrite ci-dessus, il n'est pas nécessaire de démarrer en mode gui (et c'est impossible sans un serveur X).

Pendant le démarrage de votre machine virtuelle, dans une fenêtre de terminal distincte, découvrez simplement l'ID de la machine en cours d'exécution.

vboxmanage list runningvms

Cela se traduira par quelque chose comme ceci:

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

Très souvent, la machine virtuelle attend simplement que vous sélectionniez une option dans le chargeur de démarrage. Vous pouvez envoyer le code clé approprié (dans le cas, Enter) au vm avec controlvm:

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

C'est ça. Votre machine virtuelle poursuivra 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 délais d'attente, mais je ne pouvais voir qu'un écran noir dans l'interface graphique.

Un ordinateur portable que je venais d'installer montrait toujours le même problème. Après des heures de recherche, j'ai finalement trouvé une astuce pour voir si le BIOS avait la virtualisation matérielle activée.

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

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

• Assurez-vous que votre pare-feu ou antivirus ne bloque pas le programme (ce qui, je le doute, se produira souvent)
• Donnez à votre machine vagabonde un certain temps pour que des temps morts se produisent. Si vous n'avez pas de PC / Mac très rapide, la machine virtuelle prendra du temps pour démarrer dans un état prêt SSH, donc des délais d'attente se produiront.
• Par conséquent, essayez d'abord de laisser le délai d'attente vagabond COMPLÈTEMENT avant de conclure à une erreur.
• Si le vagabond expire complètement, augmentez la limite de temporisation dans le fichier vagabond à quelques minutes et réessayez.
• Si cela ne fonctionne toujours pas, essayez de nettoyer votre machine vagabonde via l'interface VirtualBox et activez au préalable l'interface graphique de la machine. Si l'interface graphique ne montre rien qui se passe (c'est-à-dire juste un écran noir, pas de texte) pendant le démarrage, alors votre machine vagabonde a des problèmes.
• Détruisez la machine entière via l'interface VB et réinstallez.
• Supprimez les fichiers image ubuntu dans le dossier Vagrant Images dans le dossier utilisateur, puis téléchargez à nouveau et installez.
• Avez-vous même un processeur Intel qui prend en charge la virtualisation matérielle 64 bits? Recherche le sur Google. Si vous le faites, assurez-vous qu'aucun paramètre dans votre BIOS ne désactive cette fonction.
• Désactivez la fonction hyper-v si vous exécutez Windows 7 ou 8. Google comment désactiver.
• Assurez-vous que vous exécutez via un client compatible SSH. Utilisez Git bash. Téléchargement: http://git-scm.com/downloads
• Installez une version 32 bits d'ubuntu comme trusty32 ou precise32. Modifiez simplement la version dans le fichier vagrant et réinstallez vagrant dans le nouveau répertoire.
• Assurez-vous que vous utilisez les dernières versions de vagrant et de virtualbox. Derniers recours: formatez votre ordinateur, réinstallez Windows et achetez un processeur isomething Intel Core.

J'espère que cela pourra aider.

La solution que j'ai trouvée est de vérifier l'option de connexion du câble dans l'adaptateur 1 qui est attaché au NAT. Je ne sais vraiment pas, c'est ma 4ème boîte vagabonde mais c'est la seule avec l'option de connexion par câble non cochée, et après l'avoir vérifiée, cela fonctionne.

J'avais exactement le même problème. Je pensais que le problème pouvait être avec les clés SSH (mauvaise localisation du fichier ou autre chose mais je l'ai vérifié plusieurs fois) mais vous pouvez toujours ajouter dans la section configure le nom d'utilisateur et le mot de passe (sans utiliser les clés ssh) et exécuter gui pour que le code dedans Vagrantfiledevrait ressembler comme 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 l'interface graphique était affichée, j'ai eu un écran noir (pas d'erreurs ou de possibilité de connexion ou quoi que ce soit d'autre) et dans la console, j'ai eu le Error: Connection timeout. Retrying... nombreuses fois. Je me suis assuré que le VT-x (virtualisation) était activé dans le BIOS, j'ai vérifié de nombreuses combinaisons de versions de Virtual Box et de Vagrant ensemble et de nombreuses boîtes de Vagrant (pour certaines d'entre elles, je n'avais pas d'écran noir dans l'interface graphique mais toujours connecté problèmes). Enfin, j'ai à nouveau mis à jour VirtualBox et Vagrant vers les dernières versions et le problème persiste.

La chose cruciale était de regarder les icônes dans VirtualBox après avoir exécuté vagrantup (avec GUI Vagrantfilecomme je l'ai montré ci-dessus) comme sur l'image ci-dessous

Bien que je n'ai eu aucune erreur dans VirtualPC (aucun avertissement indiquant que VT-x n'est pas activé), mon Vicône était auparavant grise, ce qui signifie que le VT-x était désactivé. Comme je l'ai dit, je l'ai toujours activé dans mon BIOS.

Enfin, j'ai réalisé le problème par HYPER-Vlequel j'ai également installé et activé pour tester des sites sur Internet Explorer plus ancien. Je suis allé à Windows Control Panel -> Programs and functions / Softwareet j'ai choisi dans le menu de gauche Turn on or Turn off Windows functions(j'espère que vous les trouverez, j'utilise Windows polonais donc je ne connais pas les noms anglais exacts). J'ai désactivé Hyper-V, redémarré le PC et après avoir exécuté Virtual Box et vagrant upje n'ai finalement eu aucune erreur, dans l'interface graphique, j'ai un écran de connexion et mon Vicône s'est arrêtée pour être grise.

J'ai perdu beaucoup de temps à résoudre ce problème (et de nombreux redémarrages de PC), donc j'espère que cela pourrait être utile à tous ceux qui ont des problèmes sur Windows - assurez-vous que Hyper-V est désactivé dans votre panneau de configuration.

Le mien fonctionnait bien, puis ce "Avertissement: déconnexion de la connexion à distance. Réessayer ..." encore et encore - peut-être 20 fois - jusqu'à ce qu'il se connecte. Sur la base des réponses ci-dessus, je viens

vagrant destroy
vagrant up

et c'était tout bon. Le mien était très simple mais je l'ai fait de cette façon en réduisant le Vagrantfile au juste config.vm.box = "ubuntu/trusty64"et il le faisait toujours. Voilà pourquoi détruire et recommencer semblait le meilleur choix. Étant donné la nature apatride de ces images Vagrant, je ne vois pas pourquoi cela ne fonctionnerait pas dans tous les cas. Je ne fais que commencer et je peux encore apprendre que ce n'est pas vrai.

J'ai rencontré 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. Le correctif dans mon cas désactivait "Hyper V"

Citation de la documentation Vagrant https://docs.vagrantup.com/v2/hyperv/index.html

Avertissement: l'activation d'Hyper-V entraînera la désactivation de VirtualBox, VMware et de toute autre technologie de virtualisation. Voir cet article 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 moments où vous aurez besoin d'autres hyperviseurs.

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

1. Modifiez les paramètres du BIOS pour permettre la virtualisation de 64 bits.
2. Voici comment:
   • Redémarrez le PC à l'aide du démarrage avancé (allez dans Démarrage avancé - «redémarrer maintenant» - «dépanner» - «option avancée» - «Paramètre du firmware UEFI» - «Redémarrer»)
   • Dans la fenêtre du BIOS - Allez dans le menu / onglet «Avancé» - Activez «Intel Virtual Technology»
   • Enregistrer et quitter.

J'ai eu un problème avec une boîte existante (je ne sais pas ce qui a changé), mais j'ai pu me connecter via SSH, même si la boîte Vagrant n'a pas pu démarrer. Il se trouve que ma clé SSH avait changé d'une manière ou d'une autre.

À partir du dossier racine vagabond que j'ai exécuté, vagrant ssh-configqui m'a dit où se trouvait le fichier de clé. J'ai ouvert cela avec puttygen , puis cela m'a donné une nouvelle clé.

Sur mon invité Linux, j'ai édité ~/.ssh/authorized_keyset déposé la nouvelle clé publique là-dedans.

Tout fonctionne à nouveau - pour l'instant!

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

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

La VM s'est bien chargée après avoir remis cette ligne.

Le délai d'expiration 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 ),
• non concordance 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'ISO du programme d'installation),
• Mauvaise configuration du pare-feu VM (par exemple iptablesconfiguration ),
• règles de pare-feu local, conflit de port ou conflit avec un logiciel VPN,
• sshd mauvaise configuration.

Pour déboguer le problème, veuillez l'exécuter une --debugoption ou comme:

VAGRANT_LOG=debug vagrant up

S'il n'y a rien d'évident, essayez de vous y connecter depuis un autre terminal, par vagrant sshou par:

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

Si le SSH échoue toujours, essayez de l'exécuter avec une interface graphique (par exemple config.gui = true).

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

S'il s'agit d'une machine virtuelle jetable, vous pouvez toujours essayer destroyet uprecommencer.

Vous devriez également envisager de mettre à niveau votre Vagrant et Virtualbox.

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

J'ai eu le même problème, mais aucune des autres réponses n'a complètement résolu mon problème. La réponse de @Kiee a été utile, bien que tout ce que je pouvais voir dans l'interface graphique était un écran noir (avec un soulignement en haut à gauche, ce problème dans Virtual Box a également été soulevé 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: vérifier la 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 Virtual Box, puis ouvrez le terminal et exécutez

vagrant up

attends la ligne

default: SSH auth method: private key

vous pouvez maintenant appuyer sur ctrl + C (ou attendre le délai d'expiration) et exécuter

vagrant halt

votre machine virtuelle ne sera pas détruite, vous pouvez donc la voir dans le menu de Virtual Box, mais elle sera éteinte, vous pourrez donc modifier 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 bits)'. Après ce typevagrant up nouveau.

Si c'est un cas pour vous (ou si différents changements dans 'Paramètres' ont résolu votre problème), vous pouvez créer une nouvelle boîte à partir de la réparation réparée

vagrant package --output mynew.box

Quelques détails supplémentaires: hôte Ubuntu 12.04 32 bits, 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 apporter ma petite contribution aussi. J'ai eu 2 problèmes différents:

1. vagrant upn'a pas été en mesure de 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 "[email protected]", basé sur cet article de GitHub , et voilá, ai traversé cela;

2. Ensuite, j'ai eu le même problème de cette question " Avertissement: la connexion a expiré. Réessayer ... ", éternellement ...: Donc, après avoir lu beaucoup, j'ai redémarré mon système et regardé mon BIOS (F2 pour obtenir là, sur PC), et la virtualisation était désactivée . J'ai activé cela, enregistré et redémarré le système pour vérifier s'il a changé quoi que ce soit.

Après ça, ça a vagrant upfonctionné comme un charme! Il est 4h du matin mais ça tourne! C'est cool, hein? : D Comme je sais qu'il y a très peu de développeurs masochistes comme moi, qui essaieraient cela sous Windows, spécialement sous Windows 10 , je ne pouvais pas ne pas oublier de venir ici et de laisser ma parole ... une autre information importante, c'est que, J'essayais de configurer Laravel 5 , en utilisant Homestead, VirtualBox, composer etc. Cela a fonctionné. Donc, j'espère que cette réponse aide comme cette question et les réponses m'ont aidé. Mes meilleurs voeux. Au revoir!

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é, j'ai fait un arrêt vagabond, mais quand j'ai couru, vagrant upj'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 (à l'exception de la destruction vagabonde, qui aurait certainement résolu mon problème, mais qui était un dernier recours dans mon cas). Le message de @Kiee m'a donné l'idée d'essayer de démarrer ma machine virtuelle directement à partir de l'interface graphique de VirtualBox. Au cours du processus de démarrage, la machine virtuelle s'est arrêtée et me demandait si je voulais ignorer le montage du dossier de test que j'avais ajouté précédemment /etc/fstab. (C'est pourquoi vagrant n'a pas pu démarrer la VM.) Après avoir répondu «NON», la VM n'a démarré aucun problème. Je me suis connecté, j'ai supprimé la ligne coquine de mon fstab et j'ai arrêté la machine virtuelle.

Après ce vagabond a pu démarrer très bien.

À emporter? Si tout d'un coup, un vagabond ne peut pas redémarrer dans votre machine virtuelle, essayez de démarrer directement à partir du fournisseur (VirtualBox dans mon cas). Il y a de fortes chances que votre démarrage soit suspendu à quelque chose de totalement indépendant de SSH.

J'ai eu le même problème lorsque j'utilisais une boîte x64 (chef / ubuntu-14.04).

Je suis passé à x32 et cela a fonctionné (hashicorp / precise32).

C'est peut-être une réponse trop simple pour aider beaucoup de gens, mais cela vaut la peine d'essayer si vous ne l'avez pas fait: Faites un "arrêt vagabond" au lieu d'une "suspension vagabonde" puis redémarrez la machine virtuelle avec "vagrant up".

Je pense que mon problème était dû à un processus "kworker" qui devenait bogué et qui se terminait constamment dans la machine virtuelle et donc faire un redémarrage dur semblait recharger le processus correctement tandis qu'une sauvegarde et une restauration restituaient simplement le processus cassé dans son état cassé.

Je l'ai obtenu lors de l'exécution de vagrant / VirtualBox dans VirtualBox. J'ai résolu ce problème en exécutant la machine vagabonde sur la machine hôte.

J'ai découvert que sur MacOS avec VirtualBox l'ajout de Vagrantfile vous permettra d'aller plus loin:

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

L'installation d'un ubuntu32 bits sur un bits AMD64 a fait l'affaire. Je n'ai pas accès aux BIO car c'est un environnement restreint, mais j'ai quand même réussi à le faire fonctionner avec ubuntu / trusty32 au lieu d'ubuntu / trusty64

Utilisation de Vagrant 1.6.3 avec VirtualBox 4.3.15 sur Windows 7 SP1

J'espère que cela pourra aider.

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

Je suis sur Windows 10 et ce que j'ai fait j'ai désinstallé la boîte virtuelle et vagabonde

Ensuite, installez une ancienne version de Virtual Box spécifiquement la version 4.3.38 (Installez également le pack d'extension pour cette version)

Puis installé la dernière copie de vagabond (1.8.5 pour le moment)

Après cela, cela a fonctionné.

Si vous ne souhaitez pas activer l'interface graphique et que vous devez ensuite la désactiver ultérieurement, vous pouvez également installer le pack d'extension à partir d'Oracle:

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

Ensuite, mettez cela dans votre Vagrantfile pour activer VRDP:

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

Vous pouvez maintenant utiliser RDP pour vous connecter à votre box à la demande sans que SSH soit en cours d'exécution ou que l'interface graphique soit ouverte tout le temps.

Une autre solution possible 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 en conflit

J'ai rencontré le même problème. J'ai corrigé cela en activant Virtualizationdepuis la BIOSconfiguration.

Supprimez le fichier:

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

Exécutez ensuite:

vagrant up

Ce qui a fonctionné pour moi, c'était d'autoriser la virtualisation 64 bits sur un système d'exploitation 64 bits (Ubuntu 13.10) à partir du BIOS.

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

Dans mon cas, lui donner une adresse IP statique, a simplement résolu le problème:

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

FWIW-- Mon problème était dû à l'utilisation d'un fichier de configuration vraiment ancien au lieu d'un nouveau. L'utilisation du nouveau fichier de configuration (et donc du DSL modifié / modifié) a résolu mes problèmes instantanément.

Ce qui m'a aidé, c'est l'activation de la virtualisation dans le BIOS, car la machine n'a pas démarré.

Plutôt que de ctrl-d-ing hors de la boîte virtuelle comme je n'ai pas l'habitude de faire chaque fois que je ssh dans quelque chose, je crois que vagabond préférerait que vous entriez dans un autre terminal et fassiez:

vagrant halt

pour arrêter la boîte. Il n'y aura alors aucun problème pour revenir dans le VB.