it-swarm.com.ru

Vagrant застрял соединение тайм-аут повторной попытки

Мой бродяга отлично работал прошлой ночью. Я только что включил компьютер, нажал vagrant up, и вот что я получаю:

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

Кто-нибудь имел это раньше? vagrant еще широко не освещается в Интернете, и я не могу найти причину, почему это происходит.

413
Kiee

Я решил эту проблему и отвечу на случай, если у кого-то еще возникнет аналогичная проблема.

Что я сделал: я включил графический интерфейс виртуальной машины, чтобы увидеть, что он ожидает ввода при запуске, чтобы выбрать, хочу ли я загружаться напрямую в Ubuntu или SafeMode и т.д.

Чтобы включить графический интерфейс, вы должны поместить это в свой vagrant config Vagrantfile:

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

Когда вы застряли на своем бродячем компьютере описанным выше способом, нет необходимости загружаться в графическом режиме (и это невозможно без X-сервера).

Пока ваша VM загружается, в отдельном окне терминала просто найдите идентификатор работающей машины.

vboxmanage list runningvms

Это приведет к чему-то вроде этого:

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

Довольно часто VM просто ждет, когда вы выберете опцию в загрузчике. Вы можете отправить соответствующий код ключа (в случае, Enter) к виртуальной машине с controlvm:

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

Вот и все. Ваша виртуальная машина продолжит процесс загрузки.

211
harrie

Одна вещь, которую нужно проверить дважды, - включена ли аппаратная виртуализация в BIOS вашей машины.

Моя проблема - та же строка таймаутов, но я мог видеть только черный экран в графическом интерфейсе.

Ноутбук, который я только что настраивал, продолжал показывать ту же проблему. После нескольких часов поиска я наконец-то нашел подсказку, чтобы узнать, была ли в BIOS включена аппаратная виртуализация.

Вот содержание поста, который я нашел:

Я вижу, что есть еще пользователи, которые испытывают эту проблему. Итак, я попытаюсь обобщить приведенный ниже список некоторых возможных решений проблемы тайм-аута SSH:

  • Убедитесь, что ваш брандмауэр или антивирус не блокирует программу (что, я сомневаюсь, случится часто)
  • Дайте вашему бродячему аппарату некоторое время, чтобы произошло время ожидания. Если у вас нет очень быстрого ПК/Mac, VM потребуется некоторое время для загрузки в состояние готовности SSH, поэтому тайм-ауты будут.
  • Поэтому сначала попытайтесь ПОЛНОСТЬЮ разрешить бродячему таймауту, прежде чем решите, что произошла ошибка.
  • Если время vagrant полностью истекло, увеличьте лимит времени ожидания в файле vagrant до нескольких минут и повторите попытку.
  • Если это по-прежнему не работает, попробуйте очистить загрузочную машину через интерфейс VirtualBox и заранее включить графический интерфейс компьютера. Если графический интерфейс не показывает ничего происходящего (т. Е. Только черный экран, без текста) во время загрузки, то у вашего бродячего компьютера возникли проблемы.
  • Уничтожьте всю машину через интерфейс VB и переустановите.
  • Удалите файлы образов Ubuntu в папке Vagrant Images в папке пользователя, а затем снова загрузите и установите.
  • У вас даже есть процессор Intel, который поддерживает 64-битную аппаратную виртуализацию? Погугли это. Если вы это сделаете, убедитесь, что в вашем BIOS нет настроек, отключающих эту функцию.
  • Отключите функцию hyper-v, если вы используете Windows 7 или 8. Google, как отключить.
  • Убедитесь, что вы используете клиент с поддержкой SSH. Используйте Git Bash. Загрузить: http://git-scm.com/downloads
  • Установите 32-битную версию Ubuntu, такую ​​как trusty32 или precision32. Просто измените версию в файле vagrant и переустановите vagrant в новый каталог.
  • Убедитесь, что вы используете последние версии vagrant и virtualbox. Последнее средство: отформатируйте компьютер, переустановите Windows и купите процессор Intel Core isomething.

Надеюсь, это поможет.

47
Japo Domingo

Решение, которое я нашел, состоит в том, чтобы проверить вариант подключения кабеля в адаптере 1, который подключен к NAT. Я действительно не знаю, это мой 4-й бродячий ящик, но это единственный, где опция кабельного соединения не проверена, и после проверки она работает .  NAT cable connection

42
Cedric

У меня была точно такая же проблема. Я думал, что проблема может быть с ключами SSH (неправильная локализация файла или что-то еще, но я проверял это много раз), но вы всегда можете добавить в раздел конфигурации имя пользователя и пароль (без использования ключей ssh) и запуск графического интерфейса, так что код в Vagrantfile должен выглядеть более или менее, как показано ниже:

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

В моем случае, даже если отображался графический интерфейс, у меня был черный экран (без ошибок или возможности входа или чего-либо еще), а в консоли я получал Error: Connection timeout. Retrying... много раз. Я удостоверился, что у меня включен VT-x (виртуализация) в BIOS, я проверил много комбинаций версий Virtual Box и Vagrant вместе и много Vagrant-боксов (для некоторых из них у меня не было черного экрана в графическом интерфейсе, но все еще было соединение проблемы). Наконец я снова обновил VirtualBox и Vagrant до последних версий, и проблема все еще возникла.

Решающим моментом было рассмотрение значков в VirtualBox после запуска vagrantup (с графическим интерфейсом в Vagrantfile, как я показал выше), как показано на рисунке ниже.

enter image description here

Хотя у меня не было ошибок в VirtualPC (без предупреждений о том, что VT-x не включен), мой значок V ранее был серым, поэтому он означает, что VT-x был отключен. Как я уже сказал, он был включен в моем BIOS все время. 

Наконец, я понял, что проблема может быть в HYPER-V, который я также установил и включил для тестирования сайтов в более старых Internet Explorer. Я зашел в Windows Control Panel -> Programs and functions / Software и выбрал в меню слева Turn on or Turn off Windows functions (надеюсь, вы их найдете, я пользуюсь польской Windows, поэтому не знаю точных английских имен). Я выключил Hyper-V, перезапустил ПК и после запуска Virtual Box и vagrant up у меня наконец не возникло ошибок, в GUI у меня есть экран входа в систему, и мой значок V перестал быть серым. 

Я потратил много времени на решение этой проблемы (и много перезагрузок ПК), поэтому я надеюсь, что это может быть полезно для всех, у кого есть проблемы в Windows - убедитесь, что у вас отключен Hyper-V на панели управления.

34
Marcin Nabiałek

Мой работал нормально, а затем это «Предупреждение: удаленное соединение отключено. Повторная попытка ...» снова и снова - возможно, 20 раз - до его подключения. Основываясь на ответах выше, я просто

vagrant destroy
vagrant up

и все было хорошо. Мой был очень прост, но я сделал это таким образом, сократив Vagrantfile до config.vm.box = "ubuntu/trusty64", и он все еще делал это. Вот почему уничтожение и запуск снова казались лучшим выбором. Учитывая безгражданскую природу этих бродячих образов, я не понимаю, почему это не сработало бы в каждом случае. Я только вхожу в это, и я все еще могу понять, что это неправда.

30
HankCa

Я столкнулся с той же проблемой на компьютере с Windows 8.1. Тайм-аут соединения и включение графического интерфейса не были полезны вообще, экран был черным. Исправление в моем случае было отключение "Hyper V"

Цитата из документации Vagrant https://docs.vagrantup.com/v2/hyperv/index.html

Предупреждение. Включение Hyper-V приведет к тому, что VirtualBox, VMware и любые другие технологии виртуализации перестанут работать. См. Этот пост в блоге https://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx / для простого способа создания загрузочной записи для загрузки Windows без включенной Hyper-V, если потребуется время другие гипервизоры.

19
kri

Если вы работаете на Windows 8 или 10, это то, что у меня сработало:

  1. Измените настройки BIOS, чтобы разрешить виртуализацию 64 бит.
  2. Вот как:
    • Перезагрузите компьютер с помощью расширенного запуска (перейдите в раздел «Расширенный запуск» - «перезагрузить сейчас» - «устранить неполадки» - «расширенный параметр» - «Настройка прошивки UEFI» - «перезагрузить»)
    • Внутри окна BIOS - перейдите в меню/вкладка «Дополнительно» - Включите «Виртуальные технологии Intel»
    • Сохранить и выйти.
17
Geshan

У меня была та же проблема после того, как я удалил эту строку из моего Vagrantfile:

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

ВМ загрузилась нормально после того, как я вернул эту строку.

8
Dmitrii Mikhailov

У меня была проблема с этим с существующей коробкой (не уверен, что изменилось), но я мог подключиться через SSH, даже при том, что коробка Vagrant не загружалась. Так случилось, что мой SSH-ключ как-то изменился.

Из корневой папки vagrant я запустил vagrant ssh-config, который сказал мне, где находится файл ключа. Я открыл это с puttygen , а затем он дал мне новый ключ.

На моем госте в Linux я отредактировал ~/.ssh/authorized_keys и добавил туда новый открытый ключ.

Все снова работает - пока!

8
Steve Browett

Тайм-аут соединения SSH во время начальной загрузки может быть связан с различными причинами, такими как:

  • проверьте, включена ли виртуализация в BIOS (согласно комментарий ),
  • система ожидает взаимодействия с пользователем (например, общий ресурс не готов ),
  • несоответствие вашего личного ключа (проверьте конфигурацию через vagrant ssh-config),
  • процесс загрузки занимает гораздо больше времени (попробуйте увеличить config.vm.boot_timeout),
  • он загружается не с того диска (например, из установщика ISO),
  • Неправильная конфигурация брандмауэра ВМ (например, iptables конфигурация ),
  • локальные правила брандмауэра, конфликт портов или конфликт с программным обеспечением VPN,
  • sshd неверная конфигурация.

Чтобы устранить проблему, запустите ее с параметром --debug или как:

VAGRANT_LOG=debug vagrant up

Если нет ничего очевидного, попробуйте подключиться к нему с другого терминала, с помощью vagrant ssh или:

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

Если SSH по-прежнему не работает, попробуйте запустить его с GUI (например, config.gui = true).

Если это не так, проверьте запущенные процессы (например, с помощью: vagrant ssh -c 'pstree -a') или проверьте свой sshd_config.


Если это одноразовая виртуальная машина, вы всегда можете попробовать destroy и up снова.

Вам также следует рассмотреть возможность обновления вашего Vagrant и Virtualbox.


Для получения дополнительной информации посетите страницу Отладка и устранение неполадок .

5
kenorb

Здесь много хороших ответов, и я не мог прочитать все это, но я просто пришел, чтобы внести свой небольшой вклад. У меня было 2 разные проблемы:

  1. vagrant up не смог найти мой ssh ​​'id_rsa' (потому что у меня его тогда еще не было): Я запустил ssh-keygen -t rsa -b 4096 -C "[email protected]", основываясь на статье этого GitHub , и вуаля , прошел через это;

  2. Затем у меня возникла та же проблема с этим вопросом: «Предупреждение. Время соединения истекло. Повторная попытка ...», вечно ...: Итак, после прочтения я перезапустил свою систему и посмотрел в моем BIOS (F2, чтобы попасть туда, на ПК), и там были виртуализация отключена. Я включил это, сохранил и снова запустил систему, чтобы проверить, изменилось ли что-нибудь.

После этого vagrant up работал как шарм! Сейчас 4 утра, но он работает! Как здорово, ха? : D Как я знаю, очень немногие разработчики мазохистов, подобные мне, попробовали бы это в Windows, особенно в Windows 10, я просто не мог не забыть прийти сюда и оставил свое Word ... еще одна важная информация Я пытался настроить Laravel 5, используя Homestead, VirtualBox, composer и т. д. Это сработало. Итак, надеюсь, что этот ответ поможет, как этот вопрос и ответы помогли мне. Мои наилучшие пожелания. G-бай!

4
giovannipds

У меня была такая же проблема, но ни один из других ответов полностью не решил мою проблему. Ответ от @Kiee был полезен, хотя все, что я мог видеть в графическом интерфейсе, это черный экран (с подчеркиванием в верхнем левом углу, эта проблема в Virtual Box также поднималась отдельно при переполнении стека, опять же, ничего не помогло).

В конце концов, решение оказалось очень простым: проверьте версию вашей виртуальной машины.

Точнее, у меня был ящик от кого-то с 64-битным Debian, но Virtual Box настаивал на том, чтобы рассматривать его как 32-битный, чего я не заметил. Чтобы изменить его, откройте Virtual Box, затем откройте терминал и запустите

vagrant up

ждать линии

default: SSH auth method: private key

теперь вы можете нажать Ctrl + C (или подождать тайм-аут) и запустить

vagrant halt

ваша виртуальная машина не будет уничтожена, поэтому вы можете увидеть ее в меню Virtual Box, но она будет отключена, чтобы вы могли изменить настройки. Выберите свой компьютер в меню, нажмите «Настройки» -> «Общие» и выберите правильную «Версию», для меня это был «Debian (64-bit)». После этого снова введите vagrant up.

Если это ваш случай (или другие изменения в «Настройках» решили вашу проблему), вы можете создать новый ящик из отремонтированного, набрав

vagrant package --output mynew.box

Некоторые подробности: Хост 32-битный Ubuntu 12.04, гостевой 64-битный Debian 8.1, Virtual Box 5.0.14, Vagrant 1.8.1

4
Gwidryj

Я тестировал смонтированную папку в моем бродяге VM, добавляя новую запись в /etc/fstab. Позже я вышел из системы, запустил vagrant halt, но когда я запустил vagrant up, я получил:

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

Я прочитал все эти посты и перепробовал все те, которые казались актуальными для моего случая (кроме vagrant destroy, который наверняка решил бы мою проблему, но был последним средством в моем случае). Пост @Kiee дал мне идею попробовать загрузить мой VM непосредственно из графического интерфейса VirtualBox. В процессе загрузки VM остановился и спросил меня, не хочу ли я пропустить монтирование тестовой папки, которую я добавил ранее в /etc/fstab. (Вот почему vagrant не может загрузить виртуальную машину.) После ответа «НЕТ» VM загрузился без проблем. Я вошел в систему, удалил непослушную строку из моего fstab и выключил виртуальную машину.

После этого бродяга смог нормально загрузиться.

Вынос? Если вдруг vagrant не может загрузиться обратно на вашу виртуальную машину, попробуйте загрузиться напрямую от провайдера (VirtualBox в моем случае). Скорее всего, ваш ботинок висит на чем-то совершенно не связанном с SSH.

4
wmaddox

У меня была такая же проблема, когда я использовал x64 box (chef/ubuntu-14.04).

Я изменил на x32, и он работал (hashicorp/точный32).

3
Andrii Furmanets

Я получил это при запуске vagrant/VirtualBox внутри VirtualBox. Я решил это, запустив бродячую машину на хост-машине.

3
Jarzka

Возможно, это слишком простой ответ, чтобы помочь многим людям, но стоит попробовать, если у вас нет: выполните «vagrant halt» вместо «vagrant suspend», затем перезапустите VM с «vagrant up».

Я думаю, что моя проблема была из-за того, что какой-то процесс «kworker» глючил и постоянно зависал в VM, и поэтому полная перезагрузка, казалось, корректно перезагружала процесс, тогда как сохранение и восстановление просто восстанавливали поврежденный процесс в его работе. сломанное состояние.

3
Ambulare

Для меня это была совместимость между бродячей и виртуальной коробкой.

Я на Windows 10 и что я сделал, я удалил бродягу и виртуальный ящик

Затем установите старую версию виртуальной коробки, а именно версию 4.3.38 (установите пакет расширений для этой версии)

Затем установлена ​​последняя версия vagrant (на данный момент 1.8.5)

После этого это сработало.

2
Jplus2

Установка битов ubuntu32 на биты AMD64 сделала свое дело. У меня нет доступа к BIO, так как это ограниченная среда, но я все же смог заставить его работать с ubuntu/trusty32 вместо ubuntu/trusty64

Использование Vagrant 1.6.3 с VirtualBox 4.3.15 в Windows 7 SP1

надеюсь, это поможет.

2
fracca

Я обнаружил, что на MacOS с VirtualBox добавление этого в Vagrantfile позволит вам пойти дальше: 

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

Если вы не хотите включать графический интерфейс, а затем должны отключить его позже, вы также можете установить пакет расширений из Oracle:

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

Затем поместите это в ваш Vagrantfile, чтобы включить VRDP:

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

Теперь вы можете использовать RDP для подключения к вашему устройству по требованию без необходимости работы SSH или открытого графического интерфейса.

1
JustinParker

Убедитесь, что виртуализация вашего процессора в настройках BIOS включена.

1
jesuismasoud

Я столкнулся с той же проблемой. Я исправил это, включив Virtualization из настройки BIOS.

1
Mahbub

Удалить файл:

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

Затем запустите:

vagrant up
1
user1108948

Что мне помогло, так это возможность 64-битной виртуализации на 64-битной ОС (Ubuntu 13.10) из BIOS. 

1
Geshan

Еще одно возможное решение для пользователей провайдера VMware: Для меня проблема была решена после удаления параллельной установки VirtualBox на том же хост-компьютере. Сетевые интерфейсы между VMware и VirtualBox явно конфликтовали

1
Hinnerk

Вместо того, чтобы делать ctrl-d-out из виртуальной коробки, как я обычно делаю всякий раз, когда я ssh во что-либо, я считаю, что vagrant предпочел бы, чтобы вы вошли в другой терминал и сделали:

vagrant halt

остановить коробку. Тогда не будет проблем с возвращением назад в VB.

0
rachel

У меня была такая же проблема с Vagrant 1.6.5 и Virtual Box 4.3.16 . Решение, описанное по адресу https://github.com/mitchellh/vagrant/issues/4470 отлично работало для меня, я просто пришлось удалить VirtualBox 4.3.16 и установить старую версию 4.3.12.

0
Tugdual

Отключен брандмауэр iptables внутри виртуальной машины

Вот как я это решил:

  • Я включил графический интерфейс в моей Vagrantfile (это файл конфигурации)
  • Я мог войти в работающий VM в Gui со стандартным именем пользователя vagrant и паролем vagrant
  • Я отключил работающий брандмауэр iptables внутри виртуальной машины

Это решило мою проблему, я обнаружил, что брандмауэр блокировал все IP-адреса из локальных сетей, таких как 192.168.x.x и 10.x.x.x

Добавление правила в /etc/iptables.d/199-allow-wan, чтобы разрешить все соединения от wan:

ip46tables -A wan-input -j ACCEPT

(ip46tables - это псевдоним), см. этот коммит в моем примере Vagrant сообщества Freifunk

0
rubo77

Мое решение этой проблемы состояло в том, что мой старый ноутбук слишком долго загружался, чтобы запуститься. Я открыл Virtual Box, подключился к коробке и стал ждать загрузки экрана. Прошло около 8 минут.

Затем он подключил и установил мои папки и пошел дальше.

просто будь терпеливым иногда!

0
Evildonald

Если вы используете слой-обертку (например, Kitchen CI) и используете 32-битный хост, вам придется отказаться от установки Vagrant-боксов. Их поставщиком по умолчанию является "семейство" двоичных файлов opscode.

Поэтому перед kitchen create default-ubuntu-1204 убедитесь, что вы используете:

vagrant box add default-ubuntu-1204 http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_ubuntu-12.04-i386_chef-provisionerless.box

за использование образа 32b, если ваш Хост не поддерживает виртуализацию в формате Word

0
htmldrum

Раньше это помогло переключиться на trusty32, но теперь ситуация снова ухудшилась: Я попытался использовать Homestead 2.0, и теперь у меня снова возникла проблема с тайм-аутом подключения, , Которая обычно не была бы проблемой, потому что переключение на 32-битные помогло раньше . Но теперь я не могу просто добавить строку, как config.vm.box = "ubuntu/trusty32" , поскольку у нас больше нет классического файла Homestead.yaml, значения в новом файле 2.0 Homestead.yaml, кажется, просто вставляются в реальный в фоновом режиме и нет доступного Vagrantfile, который я мог бы редактировать вручную ...

Надеюсь, кто-то может помочь ...

0
Ulrich

Как уже указывали некоторые люди, ошибка появляется, среди прочего, если образ VirtualBox не загружался должным образом. Для меня использование режима GUI на Vagrant не сильно помогло, так как показывало только черное окно. В графическом интерфейсе VirutalBox я проверил настройки на своем VM и выяснил, что каким-то образом ОС была установлена ​​неправильно (Debian 32 вместо 64-битной).

Поэтому я могу только рекомендовать проверять настройки VirtualBox VM вручную и загружать VM без использования Vagrant.

0
telina

Я получил решение, когда я убил процесс PuTTY. Потому что у меня запущены git-ssh и PuTTY. Похоже, они сражались друг с другом за доступ по ssh. Только одного достаточно.

0
user1108948

Из интерфейса virtualbox я сначала загрузился на «CD» и отключил загрузку с жесткого диска. Следовательно, он загружался с CD iso и явно не на ожидаемой машине ... Надеюсь, это поможет. И я надеюсь, что это тоже заставило кого-то улыбнуться ... PEBCAK. 

0
Cedric

FWIW-- Моя проблема была из-за использования действительно старого конфигурационного файла вместо более нового. Использование нового файла конфигурации (и, следовательно, настройка/изменение DSL) мгновенно устранило мои проблемы.

0
tehprofessor

Вот как это работает для меня:

После «vagrant up» запустили виртуальную машину, выключили машину и перейдите к новым настройкам виртуальной машины в virtualbox. Затем перейдите в «Сеть» -> «Дополнительно»

Тип адаптера : я изменил с "Intel PRO XXXXX" на "PCNet-Fast" (или любой другой адптер, кроме Intel PRO, работал)

0
Tarik

Лично для меня программное обеспечение Tunnelblick VPN блокировало соединение. Теперь, когда я загружаю новые виртуальные машины, я временно отключаю Tunnelblick.

0
user4757351

То, как мне пришлось это решать, не упоминалось в этой теме, поэтому я публикую здесь подробности на случай, если это кому-нибудь еще поможет. 

Причиной этого является то, что vagrant не может подключиться к машине после загрузки. Как упоминалось в этой теме, существуют различные причины, например, что машина не загружается полностью или брандмауэр iptables блокирует SSH. 

В моем случае проблема заключалась в том, что я случайно настроил «private_network» с IP-адресом в той же подсети, что и встроенная сеть VirtualBox NAT (в моем случае 10.0.2.0/24). Это испортило сеть NAT для машины (но нигде не отображалось ошибок), и поскольку vagrant подключается через сеть NAT, он не смог подключиться, даже если машина работала и не было брандмауэров были включены.

Vagrant.configure("2") do |config|
  config.vm.network "private_network", ip: "10.0.2.31"
end

Исправление было в том, чтобы обновить мой VagrantFile и использовать IP-адрес private_network, который не конфликтовал с сетью VirtualBox NAT.

Vagrant.configure("2") do |config|
  config.vm.network "private_network", ip: "10.0.4.31"
end
0
user1522091

Я решил, просто набрав ˆC (или ctrl+C в Windows) дважды и выйдя из экрана сбоя подключения.

Затем я мог подключиться через SSH (vagrant ssh) и увидеть ошибку самостоятельно.

В моем случае это был ошибочный путь.

0
henriale

Найдите эту строку в вашем Homestead.yaml:

config.vm.network "forwarded_port", guest: 80, Host: 8080

и Правка на:

config.vm.network "forwarded_port", guest: 80, Host: 8000

затем в каталоге Homestead запустите:

vagrant destroy
vagrant up

Посмотри, работает ли это.

0
user2338925

Для меня помогло включение виртуализации в BIOS, потому что машина не загружалась.

0
Barth Zalewski

В моем случае, присвоив ему статический IP-адрес, просто решили проблему:

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

0
Alexar

Я столкнулся с той же проблемой, однако ни одно из упомянутых решений не сработало для меня! Я решил ее, опустив Vagrant до 1.6.2, и теперь он работает!

0
Seyed Jalal Hosseini

Мое решение оказалось ни один из вышеперечисленных точно. Я использую Ubuntu 14 в качестве гостя на Windows 7 Host. Я хорошо запустил этот бродячий ящик, но запустил его снова, не использовав его пару месяцев, и он продолжал работать с таймаутом соединения SSH. Оказалось, что пара ключей почему-то не работает - поэтому я скопировал открытый ключ Vagrant в Ubuntu в соответствии с инструкциями на этой странице . Но это еще не все. Затем я обнаружил, что закрытый ключ в моем базовом блоке отличается от закрытого ключа здесь . Размещение этого закрытого ключа в виде файла vagrant_private_key в C:\Users\your-user.vagrant.d\boxes\vagrant-box-name\nnnnnnnn\virtualbox после помещения открытого ключа в Ubuntu решило проблему.

0
Dan Swain