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 еще широко не освещается в Интернете, и я не могу найти причину, почему это происходит.

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

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

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

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

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

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

vboxmanage list runningvms

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

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

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

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

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

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

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

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

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

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

• Убедитесь, что ваш брандмауэр или антивирус не блокирует программу (что, я сомневаюсь, случится часто)
• Дайте вашему бродячему аппарату некоторое время, чтобы наступили тайм-ауты. Если у вас нет очень быстрого ПК / Mac, виртуальной машине потребуется время для загрузки в состояние готовности SSH, поэтому тайм-ауты будут.
• Поэтому сначала попробуйте дать БЕСПЛАТНОМУ тайм-ауту ПОЛНОСТЬЮ, прежде чем прийти к выводу, что произошла ошибка.
• Если время vagrant полностью истекло, увеличьте ограничение времени ожидания в файле vagrant до нескольких минут и повторите попытку.
• Если это по-прежнему не работает, попробуйте очистить загрузочную машину через интерфейс VirtualBox и заранее включить графический интерфейс компьютера. Если GUI не показывает ничего происходящего (т. Е. Только черный экран, без текста) во время загрузки, то у вашего бродячего компьютера есть проблемы.
• Уничтожьте всю машину через интерфейс 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.

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

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

У меня была точно такая же проблема. Я думал, что проблема может быть с ключами 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 (для некоторых из них у меня не было черного экрана в GUI, но все еще есть соединение проблемы). Наконец я снова обновил VirtualBox и Vagrant до последних версий, и проблема все еще возникла.

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

Хотя у меня не было ошибок в 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 на панели управления.

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

vagrant destroy
vagrant up

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

Я столкнулся с той же проблемой на компьютере с 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, если в некоторых случаях вам понадобятся другие гипервизоры.

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

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

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

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

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

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

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

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

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

Тайм-аут соединения 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 по-прежнему не работает, попробуйте запустить его с графическим интерфейсом (например config.gui = true).

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

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

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

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

У меня была такая же проблема, но ни один из других ответов полностью не решил мою проблему. Ответ от @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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

vagrant up

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

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

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

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

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

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

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

vagrant halt

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