Nouvelle tentative de connexion bloquée bloquée
Mon vagant fonctionnait parfaitement bien la nuit dernière. Je viens d'allumer le PC, appuyez sur vagrant up, et voici ce que je reçois:
==> 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 at-il eu cela auparavant? vagrant n'est pas encore largement couvert sur le web et je ne trouve pas de raison pour que cela se produise.
J'ai résolu ce problème et je répondrai si quelqu'un d'autre a un problème similaire.
Ce que j'ai fait est: j'ai activé l'interface graphique de Virtual Box pour voir qu'elle attendait une entrée au démarrage pour choisir de démarrer directement à Ubuntu ou à Safemode, etc.
Pour activer l'interface graphique, vous devez mettre ceci 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 interface graphique (et est impossible sans un serveur X).
Pendant que votre VM est en train de démarrer, dans une fenêtre de terminal séparée, il vous suffit de connaître l'ID de la machine en cours d'exécution.
vboxmanage list runningvms
Cela donnera quelque chose comme ça:
"projects_1234567890" {5cxxxx-cxxx-4xxx-8xxx-5xxxxxxxxxx}
Très souvent, la VM attend simplement que vous sélectionniez une option dans le chargeur de démarrage. Vous pouvez envoyer le code d'activation approprié (dans le cas, Enter) à la machine virtuelle avec controlvm:
vboxmanage controlvm projects_1234567890 keyboardputscancode 1c
C'est tout. 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 ordinateur.
Mon problème est la même chaîne de délais, mais je ne pouvais voir qu'un écran noir dans l'interface graphique.
Un ordinateur portable que je venais juste de mettre en place montrait le même problème. Après des heures de recherche, j'ai finalement trouvé un conseil pour savoir si le BIOS avait activé la virtualisation matérielle.
Voici le contenu de l'article que j'ai trouvé:
Je vois qu'il y a encore des utilisateurs qui rencontrent ce problème. Je vais donc essayer de résumer ci-dessous une liste de solutions possibles au problème de délai d’exécution de SSH:
- Assurez-vous que votre pare-feu ou votre antivirus ne bloque pas le programme (ce qui, je le doute, arrivera souvent)
- Donnez à votre machine à vagabond un peu de temps pour que les temps morts se produisent. Si vous n’avez pas un PC/Mac très rapide, il faudra du temps à la VM pour démarrer dans un état prêt pour SSH.
- Par conséquent, essayez d’abord de laisser COMPLÈTEMENT le délai d’attente du vagabond avant de conclure à une faute.
- Si vagant expire complètement, augmentez la limite de temps mort dans le fichier vagrant à quelques minutes et réessayez.
- Si cela ne fonctionne toujours pas, essayez de démarrer en mode minimal votre ordinateur virtuel via l'interface VirtualBox et activez l'interface graphique de l'ordinateur au préalable. Si l'interface graphique n'affiche rien (c'est-à-dire juste un écran noir, pas de texte) pendant le démarrage, cela signifie que votre ordinateur de poche a des problèmes.
- Détruisez l'intégralité de la machine via l'interface VB et réinstallez-la.
- Supprimez les fichiers image Ubuntu du dossier Images vagabondes du dossier utilisateur, puis téléchargez-le à nouveau et installez-le.
- Avez-vous même un processeur Intel prenant en charge la virtualisation matérielle 64 bits? Recherche le sur Google. Si vous le faites, assurez-vous qu'aucun paramètre de votre Bios ne désactive cette fonctionnalité.
- Désactivez la fonctionnalité hyper-v si vous utilisez Windows 7 ou 8. Comment désactiver Google.
- Assurez-vous que vous utilisez un client compatible SSH. Utilisez Git bash. Télécharger: http://git-scm.com/downloads
- Installez une version 32 bits d'ubuntu telle que trusty32 ou precise32. Il suffit de changer la version dans le fichier vagrant et de réinstaller vagrant dans un 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 Intel Core isomething.
J'espère que cela pourra aider.
La solution que j'ai trouvée consiste à vérifier l'option de connexion par câble dans l'adaptateur 1 connecté au NAT. Je ne sais vraiment pas, c’est ma 4e boîte à vagabond mais c’est la seule option de connexion par câble non cochée, et après vérification, cela fonctionne . 
J'ai eu 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 le nom d'utilisateur et le mot de passe de la section configure (sans utiliser les clés ssh) et exécuter gui pour que le code soit dans Vagrantfile devrait ressembler plus ou moins à ce qui suit:
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 un écran noir (pas d'erreur ni possibilité de vous connecter ou quoi que ce soit d'autre) et dans la console, j'ai reçu le Error: Connection timeout. Retrying... plusieurs fois. Je me suis assuré que VT-x (virtualisation) était activé dans le BIOS, j'ai vérifié plusieurs combinaisons de versions de Virtual Box et de Vagrant ensemble et de nombreuses boîtes Vagrant (pour certaines d'entre elles, l'écran GUI n'était pas noir, mais j'avais toujours une connexion. problèmes). Enfin, j'ai mis à jour VirtualBox et Vagrant à nouveau avec les dernières versions et le problème persiste.
L'essentiel était de regarder les icônes dans VirtualBox après avoir exécuté vagrantup (avec une interface graphique dans Vagrantfile comme je l'ai montré ci-dessus) comme sur l'image ci-dessous.
Bien que je n’ai pas eu d’erreurs dans VirtualPC (aucun avertissement indiquant que VT-x n’est pas activé), mon icône V était auparavant grisée, ce qui signifie que le VT-x a été désactivé. Comme je le disais, je l'avais activé dans mon BIOS tout le temps.
Enfin, j’ai réalisé que le problème était peut-être par HYPER-V que j’ai également installé et activé pour tester des sites sur un ancien Internet Explorer. Je suis allé à Windows Control Panel -> Programs and functions / Software et choisissez 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 up, je n'ai finalement eu aucune erreur. Dans l'interface graphique, j'ai un écran de connexion et mon icône V a cessé d'être grisée.
J'ai perdu beaucoup de temps à résoudre ce problème (et de nombreux redémarrages de PC), j'espère donc que cela pourrait être utile à quiconque a des problèmes sous Windows - assurez-vous que Hyper-V est désactivé dans votre panneau de configuration.
Le mien fonctionnait bien, puis le message "Avertissement: Déconnexion de la connexion à distance. Nouvelle tentative ..." plusieurs fois - peut-être 20 fois - jusqu'à ce qu'il soit connecté. Basé sur les 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 config.vm.box = "ubuntu/trusty64" et il le faisait toujours. C’est la raison pour laquelle détruire et recommencer semblait être le meilleur choix. Étant donné la nature apatride de ces images vagabondes, je ne vois pas pourquoi cela ne fonctionnerait pas dans tous les cas. J'entre juste dans ceci 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"
Extrait de la documentation Vagrant https://docs.vagrantup.com/v2/hyperv/index.html
Avertissement: L'activation de Hyper-V entraînera l'arrêt de VirtualBox, VMware et de toute autre technologie de virtualisation. Voir ce 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 l'option Hyper-V autres hyperviseurs.
Si vous travaillez sous Windows 8 ou 10, voici ce qui a fonctionné pour moi:
- Modifiez les paramètres du BIOS pour permettre la virtualisation de 64 bits.
- Voici comment:
- Redémarrez l'ordinateur à l'aide de la fonction de démarrage avancé (allez à la section Démarrage avancé - "redémarrer maintenant" - "dépanner" - "option avancée" - "Paramétrage UEFI Firmware" - "Redémarrer")
- Dans la fenêtre du BIOS - Allez dans le menu/onglet "Avancé" - Activez "Technologie virtuelle Intel"
- Enregistrer et quitter.
J'ai eu le même problème après avoir supprimé cette ligne de mon Vagrantfile:
config.vm.network "private_network", type: "dhcp"
VM chargé bien après avoir remis cette ligne.
J'ai eu un problème avec cela avec une boîte existante (je ne sais pas ce qui a changé), mais je pourrais me connecter via SSH, même si la boîte Vagrant n'a pas pu démarrer. En l'occurrence, ma clé SSH avait changé d'une manière ou d'une autre.
Dans le dossier racine vagabond, j'ai lancé vagrant ssh-config qui m'a indiqué où se trouvait le fichier de clé. J'ai ouvert cela avec puttygen et ensuite cela m'a donné une nouvelle clé.
Sur mon invité Linux, j'ai modifié ~/.ssh/authorized_keys et y ai déposé la nouvelle clé publique.
Tout fonctionne à nouveau - pour l'instant!
Le délai de connexion SSH au cours 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, depuis l'ISO du programme d'installation),
- Mauvaise configuration du pare-feu de la machine virtuelle (par exemple, configuration
iptables), - règles de pare-feu locales, conflit de port ou conflit avec un logiciel VPN,
sshdmauvaise configuration.
Pour déboguer le problème, lancez-le avec une option --debug ou comme ceci:
VAGRANT_LOG=debug vagrant up
S'il n'y a rien d'évident, essayez de vous y connecter depuis un autre terminal, avec vagrant ssh ou avec:
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 d'exécution (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 de destroy et up à nouveau.
Vous devriez également envisager de mettre à niveau votre Vagrant et votre Virtualbox.
Pour plus d'informations, consultez la page Débogage et Dépannage .
Il y a beaucoup de bonnes réponses ici, et je ne pouvais pas tout lire, mais je suis juste passé à donner ma petite contribution aussi. J'ai eu 2 problèmes différents:
vagrant upn'est pas parvenu à trouver mon ssh 'id_rsa' (car je ne l'avais pas encore à ce moment-là): J'ai exécutéssh-keygen -t rsa -b 4096 -C "[email protected]", sur la base de article de ce GitHub , et voila, est passé par là;Ensuite, le même problème se pose avec cette question "Avertissement: la connexion a expiré. Nouvelle tentative ...", éternellement ...: Ainsi, après avoir beaucoup lu, j'ai redémarré mon système et j'ai regardé dans mon BIOS (F2 pour y arriver, sur PC), et il y avait virtualisation désactivée. J'ai activé cela, enregistré et redémarré le système pour vérifier s'il a changé quelque chose.
Après cela, vagrant up a fonctionné à merveille! Il est 4h du matin mais ça tourne! Comment cool, hã? : D Comme je sais qu'il y a très peu de développeurs masochistes comme moi, qui voudraient essayer cela sous Windows, spécialement sous Windows 10, je ne pouvais tout simplement pas oublier de venir ici et de laisser mon mot ... une autre information importante , est-ce que j’essayais d’installer Laravel 5, en utilisant Homestead, VirtualBox, compositeur, etc. Cela a fonctionné. Donc, espérons que cette réponse aide comme cette question et les réponses m'ont aidé. Mes meilleurs voeux. G-bye!
J'ai eu le même problème, mais aucune des autres réponses n'a complètement résolu mon problème. Answer by @Kiee a été utile, même si tout ce que je pouvais voir dans l'interface graphique était un écran noir (avec un trait de soulignement en haut à gauche, ce problème dans Virtual Box a également été soulevé séparément dans le débordement de pile, là encore rien n'a aidé).
Finalement, une solution s’est révélé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 en 32 bits, ce que je n'ai pas remarqué. Pour le changer, ouvrez Virtual Box, puis ouvrez le terminal et lancez
vagrant up
attendre la ligne
default: SSH auth method: private key
maintenant vous pouvez appuyer sur ctrl + C (ou attendre le délai d’attente) et exécuter
vagrant halt
votre machine virtuelle ne sera pas détruite, vous pourrez donc la voir dans le menu de Virtual Box, mais elle sera éteinte afin que vous puissiez modifier les paramètres. Choisissez votre machine dans le menu, cliquez sur "Paramètres" -> "Général" et choisissez la "Version" appropriée. Pour moi, c'était "Debian (64 bits)". Après cela, tapez à nouveau vagrant up.
Si cela vous convient (ou si des modifications différentes dans "Paramètres" ont résolu votre problème), vous pouvez créer une nouvelle boîte à partir de la saisie réparée.
vagrant package --output mynew.box
Quelques détails supplémentaires: hôte 32 bits Ubuntu 12.04, invité Debian 8.1 64 bits, Virtual Box 5.0.14, Vagrant 1.8.1
J'ai eu le même problème lorsque j'utilisais x64 box (chef/ubuntu-14.04).
J'ai changé pour x32 et cela a fonctionné (hashicorp/precise32).
Je l’ai eu lors de l’exécution de vagrant/VirtualBox dans VirtualBox. J'ai résolu ce problème en exécutant la machine vagabonde dans la machine hôte.
C’est peut-être une solution trop simple pour aider beaucoup de gens, mais elle vaut la peine d’essayer si vous ne l’avez pas fait: faites un "arrêt de vagabond" au lieu de "suspendre un vagabond", puis redémarrez le VM avec "vagabond".
Je pense que mon problème était dû à un processus "kworker" qui devenait bogué et dont le temps passait constamment dans VM. Un redémarrage difficile semblait donc recharger correctement le processus, alors qu'une sauvegarde et une restauration ne faisaient que restaurer le processus interrompu dans son état brisé.
Pour moi, c'était la compatibilité entre vagrant et virtual box.
Je suis sur Windows 10 et ce que j'ai fait j'ai désinstallé la boîte virtuelle et vagabonde
Puis installez une ancienne version de virtual box spécifiquement la version 4.3.38
Puis installé la dernière copie de vagrant (1.8.5 pour le moment)
Après cela a fonctionné.
L'installation d'un ubuntu32 bits sur un AMD64 a fait l'affaire. Je n'ai pas accès aux BIO car son environnement est 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.
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 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 ceci dans votre Vagrantfile pour activer VRDP:
vb.customize ["modifyvm", :id, "--vrde", "on"]
Vous pouvez maintenant utiliser RDP pour vous connecter à votre boîte à la demande sans que SSH ait besoin d'être exécuté ou que l'interface graphique ne soit ouverte en permanence.
Vérifiez que la virtualisation de votre processeur dans la configuration du BIOS est activée.
J'ai rencontré le même problème. J'ai résolu ce problème en activant Virtualization à partir de la configuration BIOS.
Supprimer le fichier:
C:\Users\UserName\\.vagrant.d\insecure_private_key
Puis lancez:
vagrant up
Ce qui a fonctionné pour moi, c’était de permettre la virtualisation 64 bits sur un système d’exploitation 64 bits (Ubuntu 13.10) à partir du BIOS.
Une solution supplémentaire 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 le même ordinateur hôte. Les interfaces réseau entre VMware et VirtualBox étaient apparemment en conflit
Plutôt que de sortir de la boîte virtuelle comme je le fais d'habitude, je pense que vagrant préfèrerait que vous entrez dans un autre terminal et que
vagrant halt
pour arrêter la boîte. Il n’y aura alors aucun problème pour entrer revenir dans le VB.
J'ai eu le même problème avec Vagrant 1.6.5 et Virtual Box 4.3.16 . La solution décrite à https://github.com/mitchellh/vagrant/issues/4470 a bien fonctionné pour moi, je viens Je devais supprimer VirtualBox 4.3.16 et installer l'ancienne version 4.3.12.
Pare-feu iptables désactivé à l'intérieur de la machine virtuelle
Voici comment je l'ai résolu:
- J'ai activé l'interface graphique dans ma
Vagrantfile(c'est le fichier de configuration) - Je pourrais me connecter à la VM en cours d'exécution dans l'interface graphique avec le nom d'utilisateur standard vagrant et mot de passe vagabond
- J'ai désactivé le pare-feu iptables en cours d'exécution à l'intérieur de la machine virtuelle
J'ai ainsi découvert que le pare-feu bloquait toutes les adresses IP des réseaux locaux tels que 192.168.x.x et 10.x.x.x.
Ajouter une règle dans /etc/iptables.d/199-allow-wan pour autoriser toutes les connexions à partir de wan:
ip46tables -A wan-input -j ACCEPT
(ip46tables est un alias) voir ce commit dans mon exemple Vagrant Freifunk community
Ma solution à ce problème était que mon ancien ordinateur portable prenait wayyyyyyyyyyy trop longtemps à démarrer. J'ai ouvert Virtual Box, connecté à la boîte et attendu que l'écran se charge. A pris environ 8 minutes.
Ensuite, il a connecté et monté mes dossiers et est allé de l'avant.
soyez patient parfois!
Si vous utilisez une couche d'encapsulation (telle que Kitchen CI) et que vous utilisez un hôte 32b, vous devrez anticiper l'installation des boîtes Vagrant. Leur fournisseur par défaut est la "famille" opscode de fichiers binaires.
Donc, avant kitchen create default-ubuntu-1204, assurez-vous d’utiliser:
vagrant box add default-ubuntu-1204 http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_ubuntu-12.04-i386_chef-provisionerless.box
pour utiliser l'image 32b si votre hôte ne prend pas en charge la virtualisation de la taille Word
Auparavant, cela permettait de passer à trusty32, mais la situation s'est encore aggravée: J'ai essayé d'utiliser Homestead 2.0 et maintenant j'ai à nouveau le problème du délai de connexion, Ce qui ne serait généralement pas un problème, Parce que le passage à 32 bits a aidé avant .. .. Mais maintenant, je ne peux pas simplement ajouter une ligne comme. config.vm.box = "ubuntu/trusty32" Parce que nous n’avons plus de fichier Homestead.yaml classique, les valeurs du nouveau fichier 2.0 Homestead.yaml semblent simplement être insérées dans le vrai en arrière-plan et il n’existe aucun fichier Vagrant disponible que je puisse éditer manuellement ...
J'espère que quelqu'un peut aider ...
Comme certains l'ont déjà souligné, l'erreur apparaît, entre autres choses, si l'image de VirtualBox ne s'est pas initialisée correctement. Pour moi, utiliser le mode graphique sur Vagrant ne m'a pas beaucoup aidé car il ne montrait qu'une fenêtre noire. Dans l'interface graphique de VirutalBox, j'ai vérifié les paramètres de mon VM et constaté que le système d'exploitation était mal configuré (Debian 32 au lieu de 64 bits).
Je ne peux donc que recommander de vérifier manuellement les paramètres de VirtualBox de VM et d’obtenir le VM sans utiliser Vagrant.
Je l'ai résolu quand j'ai tué le processus PuTTY. Parce que git-ssh et PuTTY sont en cours d'exécution. Ils semblaient se battre pour avoir accès à ssh. Un seul suffit.
À partir de l'interface de la virtualbox, j'ai d'abord démarré sur un "CD", puis désactivé le démarrage du disque dur. Par conséquent, il démarrait depuis un CD iso, et évidemment pas sur la machine attendue ... J'espère que cela aide. Et j'espère que ça a fait sourire aussi quelqu'un ... PEBCAK.
FWIW-- Mon problème était dû à l'utilisation d'un très vieux fichier de configuration au lieu d'un nouveau. Utiliser le nouveau fichier de configuration (et donc modifier/modifier DSL) a résolu mes problèmes instantanément.
Voici comment cela a fonctionné pour moi:
Après que "vagrant up" ait démarré la machine virtuelle, éteignez la machine et accédez aux nouveaux paramètres de la machine virtuelle dans virtualbox. Ensuite, allez dans "Réseau" -> "Avancé"
Type d'adaptateur : j'ai remplacé "Intel PRO XXXXX" par "PCNet-Fast" (ou tout autre adresse que Intel PRO qui a fonctionné)
Personnellement, le logiciel Tunnelblick VPN bloquait la connexion. Maintenant, lorsque je démarre de nouvelles machines virtuelles, je désactive temporairement Tunnelblick.
La façon dont j'ai dû résoudre ce problème n'a pas été mentionnée dans ce fil de discussion. Je poste ici les détails au cas où cela aiderait quelqu'un d'autre.
La raison en est que vagrant ne peut pas ssh dans la machine après le démarrage. Il existe différentes raisons à cela, comme mentionné dans ce fil de discussion, telles que le fait que la machine ne démarre pas complètement ou que le pare-feu iptables bloque SSH.
Dans mon cas, le problème était que je configurais par inadvertance un "réseau privé" avec une adresse IP dans le même sous-réseau que le réseau intégré VirtualBox NAT (dans mon cas, 10.0.2.0/24). Cela a gâché le réseau NAT de la machine (mais aucune erreur n’a été signalée nulle part), et puisque vagrant se connecte via le réseau NAT, il n’a pas pu se connecter même si la machine était en marche et aucun pare-feu ont été activés.
Vagrant.configure("2") do |config|
config.vm.network "private_network", ip: "10.0.2.31"
end
Le correctif consistait à mettre à jour mon fichier VagrantFile et à utiliser une adresse IP "private_network" qui ne soit pas en conflit avec le réseau NAT de VirtualBox.
Vagrant.configure("2") do |config|
config.vm.network "private_network", ip: "10.0.4.31"
end
J'ai résolu en tapant simplement ˆC (ou ctrl+C sous Windows) deux fois et en quittant l'écran d'échec de connexion.
Ensuite, je pourrais me connecter via SSH (vagrant ssh) et voir l’erreur par moi-même.
Dans mon cas, c'était un chemin mal tracé.
Recherchez cette ligne dans votre Homestead.yaml:
config.vm.network "forwarded_port", guest: 80, Host: 8080
et passer à:
config.vm.network "forwarded_port", guest: 80, Host: 8000
puis dans le répertoire Homestead, exécutez:
vagrant destroy
vagrant up
Voyez si cela fonctionne.
Ce qui m'a aidé, c’est l’activation de la virtualisation dans le BIOS car la machine n’a pas démarré.
Dans mon cas, lui attribuer une adresse IP statique a simplement résolu le problème:
config.vm.network "private_network", ip: "192.168.50.50"
J’ai fait face au même problème, mais aucune des solutions mentionnées n’a fonctionné pour moi!
Ma solution s'est avérée être aucune de ce qui précède exactement. J'utilise Ubuntu 14 en tant qu'invité dans un hôte Windows 7. J'utilisais bien cette boîte vagabonde, mais je l'ai redémarrée après ne pas l'avoir utilisée pendant quelques mois, et le délai de connexion SSH n'arrivait pas. Il s'est avéré que la paire de clés ne fonctionnait pas - j'ai donc copié la clé publique Vagrant dans Ubuntu en suivant les instructions de cette page . Mais ce n'était pas tout. J'ai ensuite découvert que la clé privée de ma base était différente de la clé privée ici . Le fait de placer cette clé privée comme fichier vagrant_private_key dans C:\Utilisateurs\votre-utilisateur.vagrant.d\boxes\nom-boîte-vagrant\nnnnnnnn\virtualbox après avoir placé la clé publique dans Ubuntu a résolu le problème.