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

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

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

vboxmanage list runningvms

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

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

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

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

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

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

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

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

вот содержание сообщения, которое я нашел:

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

• убедитесь, что ваш брандмауэр или антивирус не блокирует программу (что, я сомневаюсь, будет происходить часто)
• дайте вашей бродячей машине некоторое время для таймаутов. Если у вас нет очень быстрого ПК / Mac, VM займет некоторое время для загрузки в состояние готовности SSH, поэтому таймауты будут происходить.
• поэтому, сначала попробуйте полностью позволить vagrant timeout, прежде чем заключить, что есть ошибка.
• если время ожидания vagrant полностью, то увеличьте ограничение тайм-аута в файле vagrant до нескольких минут и повторите попытку.
• если это все еще не работает, попробуйте очистить загрузку вашей бродячей машины через интерфейс VirtualBox и включить GUI машины заранее. Если GUI ничего не показывает (т. е. просто черный экран, без текста) пока он загружается, тогда ваш бродяга у машины проблемы.
• уничтожьте всю машину через интерфейс VB и переустановите.
• удалите файлы изображений ubuntu в папке Vagrant Images В папке user и перезагрузите и установите.
• у вас даже есть процессор intel, который поддерживает 64-битную аппаратную виртуализацию? Google его. Если вы это сделаете, убедитесь, что в Bios нет настроек, отключающих эту функцию.
• отключить функцию hyper-v, Если вы используете windows 7 или 8. Google, Как отключить.
• убедитесь, что вы работаете через клиент с поддержкой SSH. Используйте Git bash. Скачать: http://git-scm.com/downloads
• установите 32-битную версию ubuntu, такую как trusty32 или precise32. Просто измените версию в файле vagrant и переустановите vagrant в новом каталоге.
• убедитесь, что вы используете последние версии vagrant и virtualbox. Последние курорты: отформатируйте компьютер, переустановите windows и купите Intel core isomething процессор.

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

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

у меня была точно такая же проблема. Я думал, что проблема может быть с SSH-ключами (неправильная локализация файла или что-то еще, но я проверил это много раз), но вы всегда можете добавить в configure раздел имя пользователя и пароль (без использования ssh-ключей) и запустить gui, чтобы код в 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

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

самое главное было смотреть на значки в VirtualBox после запуска vagrantup (с GUI в 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 (надеюсь, вы найдете их, я использую польские окна, поэтому не знаю точных английских имен). Я выключил 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. Тайм-аут соединения и включение gui не были полезны вообще, экран был черным. Исправление в моем случае было отключено "Hyper V"

цитата из бродячей документации 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, чтобы разрешить виртуализацию 64bit.
2. вот как:
   • перезагрузите ПК с помощью расширенного запуска (перейдите к расширенному запуску - "перезагрузка сейчас"- "устранение неполадок" - "расширенный вариант" - "настройка прошивки UEFI" - "перезагрузка")
   • внутри окна BIOS-перейдите в меню/вкладку "дополнительно" - включить "Intel Virtual Technology"
   • сохранить & Выход.

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

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

на моем ГОСТе Linux я редактировал ~/.ssh/authorized_keys и сбросил новый открытый ключ в там.

все снова работает-на данный момент!

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

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

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

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

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

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

vagrant up

подождите, пока строка

default: SSH auth method: private key

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

vagrant halt

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

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

vagrant package --output mynew.box

дополнительные сведения: хост 32-разрядный Ubuntu 12.04, гостевой 64-разрядный Debian 8.1, виртуальная коробка 5.0.14, Vagrant 1.8.1

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

1. vagrant up не удалось найти мой ssh'id_rsa' (потому что в то время у меня его еще не было): Я побежал!--1--> на основе эта статья GitHub, и вуаля, шагнул через это;

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

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

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

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

чтобы отладить проблему, запустите ее или так:

VAGRANT_LOG=debug vagrant up

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

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

если SSH все еще не удается, попробуйте запустить его с графический интерфейс (например,config.gui = true).

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

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

вы также должны рассмотреть вопрос об обновлении вашего бродяги и версия VirtualBox.

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

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

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

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

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

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

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

я перешел на x32, и он работал(hashicorp / precise32).

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

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

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

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

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

надеюсь, что помогает.

для меня это была совместимость между vagrant и virtual box.

Я на windows 10, и то, что я сделал, я удалил vagrant и virtual box

затем установите старую версию virtual box конкретно версии 4.3.38 (установите пакет расширения тоже для этой версии )

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

после этого он работал.

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

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

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

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

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

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

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

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

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

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

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

запустите:

vagrant up

то, что работало для меня, позволяло 64-битную виртуализацию на 64-битной ОС (Ubuntu 13.10) из BIOS.

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

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

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

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

vagrant halt

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

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