Vagrant steckte Verbindung Timeout erneut versuchen

Question

Mein Vagrant hat gestern Abend einwandfrei funktioniert. Ich habe gerade den PC eingeschaltet, vagrant up eingegeben und das ist das Ergebnis:

==> default: Löschen zuvor festgelegter Netzwerkschnittstellen...
==> default: Vorbereiten von Netzwerkschnittstellen basierend auf der Konfiguration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Ports weiterleiten...
    default: 22 => 2222 (Adapter 1)
==> default: VM wird gebootet...
==> default: Warte darauf, dass die Maschine bootet. Dies kann einige Minuten dauern...
    default: SSH-Adresse: 127.0.0.1:2222
    default: SSH-Benutzername: vagrant
    default: SSH-Authentifizierungsmethode: privater Schlüssel
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...
    default: Fehler: Verbindungstimeout. Wiederholung...

Hatte das schon einmal jemand? Vagrant wird noch nicht weitreichend im Web behandelt und ich kann keinen Grund finden, warum dies passiert.

Answer 1

Meiner lief gut und dann kam immer wieder "Warnung: Remote-Verbindung getrennt. Wiederholung..." - vielleicht 20 Mal - bis es verbunden war. Basierend auf den oben genannten Antworten habe ich nur

vagrant destroy
vagrant up

und alles war gut. Meiner war sehr einfach, aber ich habe es so gemacht, indem ich die Vagrantfile auf nur config.vm.box = "ubuntu/trusty64" reduziert habe, und es machte es immer noch. Deshalb schien das Zerstören und Neustarten die beste Wahl zu sein. Angesichts der zustandslosen Natur dieser Vagrant-Images sehe ich nicht, warum das in jedem Fall nicht funktionieren würde. Ich steige gerade erst ein und ich könnte noch lernen, dass das nicht wahr ist.

Answer 2

Ich hatte das gleiche Problem auf einem Windows 8.1-Rechner. Der Verbindungsabbruch und das Aktivieren der grafischen Benutzeroberfläche waren nicht hilfreich, der Bildschirm blieb schwarz. Die Lösung in meinem Fall bestand darin, "Hyper-V" zu deaktivieren.

Zitat aus der Vagrant-Dokumentation https://docs.vagrantup.com/v2/hyperv/index.html

Warnung: Das Aktivieren von Hyper-V führt dazu, dass VirtualBox, VMware und andere Virtualisierungstechnologien nicht mehr funktionieren. Sehen Sie sich diesen Blog-Beitrag https://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx für eine einfache Möglichkeit an, einen Boot-Eintrag zu erstellen, um Windows ohne aktivierten Hyper-V zu starten, wenn Sie auch andere Hypervisoren benötigen.

Answer 3

Wenn Sie mit Windows 8 oder 10 arbeiten, hat dies für mich funktioniert:

1. Ändern Sie die BIOS-Einstellungen, um die Virtualisierung von 64-Bit zuzulassen.
2. So geht's:
   • Starten Sie den PC neu mit erweitertem Start (zu erweiterter Start -'jetzt neu starten'-'Problembehandlung' -'erweiterte Option'- 'UEFI-Firmware-Einstellung' - 'Neustart')
   • Im BIOS-Fenster - Gehen Sie zum Menü/Tab 'Erweitert' - Aktivieren Sie 'Intel Virtual Technology'
   • Speichern & Beenden.

Answer 4

Ich hatte dasselbe Problem, nachdem ich diese Zeile aus meiner Vagrantdatei gelöscht hatte:

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

Die VM wurde wieder erfolgreich geladen, nachdem ich diese Zeile wieder hinzugefügt habe.

Answer 5

Ich hatte ein Problem damit mit einer vorhandenen Box (nicht sicher, was sich geändert hat), aber ich konnte mich über SSH verbinden, obwohl die Vagrant-Box beim Booten fehlschlug. Wie es sich herausstellte, hatte sich mein SSH-Schlüssel irgendwie geändert.

Vom Vagrant-Stammordner aus führte ich vagrant ssh-config aus, was mir sagte, wo sich die Schlüsseldatei befand. Diese öffnete ich mit puttygen und dann gab es mir einen neuen Schlüssel.

Auf meinem Linux-Gast bearbeitete ich ~/.ssh/authorized_keys und fügte den neuen öffentlichen Schlüssel ein.

Alles funktioniert wieder - vorerst!