Vagrant times out waiting for machine to boot (Virtualbox) - vagrant

To preface, I realize this is a common error message with several different causes and solutions, but nothing I've found has worked so far. I have Vagrant 2.1.5 with Virtualbox 5.2.18, running on Windows 10.
I was testing Vagrant with a very simple Vagrantfile:
Vagrant.configure("2") do |config|
config.vm.box = "centos/7"
end
Running vagrant up then gives the typical "Timed out while waiting for the machine to boot" error:
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'centos/7'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'centos/7' is up to date...
==> default: Setting the name of the VM: vargrantTest_default_1537805339381_15444
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (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
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
Things I have tried:
Ensuring virtualization is enabled in BIOS
Increasing boot timeout in vagrantfile
Ensuring the VMs network settings are correct in Virtualbox (NAT adapter with cable connected)
Using vb.gui = true to watch the VM boot. It boots fine and waits at the login screen.
Using --debug flag on vagrant up. This doesn't give any obvious errors that I found, though before timing out it runs VBoxManage showvminfo --machinereadable several hundred times, resulting in a log file of over 80k lines.
As well as several other things I forgot to write down. I'm out of ideas and quite new to Vagrant, so I don't really know what the next step of troubleshooting this is. Any help would be appreciated.
Edit: Not sure why I didn't think to do it myself, but Marco gave me the idea to try to ssh directly to the VM. I tried doing so using the key file in "/.vagrant.d/insecure_private_key" created by Vagrant, but it timed out. I then tried to simply ping the VM, but doing so gives a seemingly random mix of "Request timed out" and "Destination host unreachable", so there's probably a bigger network issue somewhere (my machine, the VM, or Virtualbox) I'm unaware of.

Are you declaring some kind of network for this box? Either private or public, but something?
Also, how long is your boot timeout? Go overboard and give it 900=>15mn.

Related

Chef Kitchen Vagrant box will not start when adding additional disks

Development is happening on Mac OSX
Writing a cookbook to partition, format, mount drives dynamically based on drives that are not partitioned, mounted, or formatted, May have been taken out of single drive raid-0 configuration, or may not have been configured through raid controller yet...
While working on writing test cases for cookbook. I am having the following issues.
.kitchen.yml file:
driver:
name: vagrant
# ssh:
# insert_key: false
customize:
cableconnected1: 'on'
createhd:
- filename: /tmp/disk1.vdi
size: 128
storagectl:
- name: SATA Controller
portcount: 4
storageattach:
- storagectl: SATA Controller
port: 0
device: 0
type: hdd
medium: /tmp/disk1.vdi
privileged: true
Command: kitchen verify
Gets stuck at the following
Output:
-----> Starting Kitchen (v1.20.0)
$$$$$$ Deprecated configuration detected:
require_chef_omnibus
Run 'kitchen doctor' for details.
-----> Creating <default-centos-7>...
(erb):173: warning: constant ::Fixnum is deprecated
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'bento/centos-7'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'bento/centos-7' is up to date...
==> default: Setting the name of the VM: default-centos-
7_default_1526333511693_18382
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2200 (host) (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few
minutes...
default: SSH address: 127.0.0.1:2200
default: SSH username: vagrant
default: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
Will not proceed any further. The adding disk code was taken directly from the kitchen-vagrant documentation for adding a disk.
I can remove the createhd, storagectl, & storageattach sections, at which point the vagrant box works as intended.
I have verified that the /tmp/disk1.vdi file is created, I also have to delete the file between runs, after a kitchen destroy else I get the following error:
-----> Starting Kitchen (v1.20.0)
$$$$$$ Deprecated configuration detected:
require_chef_omnibus
Run 'kitchen doctor' for details.
-----> Creating <default-centos-7>...
(erb):173: warning: constant ::Fixnum is deprecated
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'bento/centos-7' is up to date...
==> default: Machine not provisioned because `--no-provision` is
specified.
Waiting for SSH service on 127.0.0.1:2200, retrying in 3 seconds
It will continue being stuck on retying in 3 seconds indefinitely until I escape the command.
I have tried with and without:
ssh:
insert_key: false
I have tried different formats of files that vagrant is supposed to support as a disk, including .vdi, .vmdk
I have ensured that SATA Controller is the appropriate controller available for the box.
This seems issue with vagrant and virtualbox versions. You can find a similar issue here
The reason for this is that kitchen/vagrant tries to bind the OS disk to port 0 of your controller. So the reason it doesn't boot is because there is no boot disk bound!
If you change port: 0 to port: 1 in your example it should boot as expected.

No Intel® Virtualization Technology (VT-x): Vagrant stumbles even with 32-bit images

CPU: Intel® Core™2 Quad CPU Q8200 # 2.33GHz × 4
Host OS: Ubuntu 16.04.2 64-bit
Vagrant: 1.9.7
Virtualbox: 5.1.24
I do:
$ vagrant init precise64 http://files.vagrantup.com/xenial32.box
...
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2200 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: 127.0.0.1:2200
default: SSH username: vagrant
default: SSH auth method: private key
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
Well, I tried xenial64.box as well. And precise32.
Here is some discussion "vagrant up" it stops at SSH auth method: private key
This seems to connected somehow with Intel Virtualization Technology.
Well, this CPU doesn't support it.
I will be satisfied with a 32 bit virtual machine. But how can I organize it? Well, I'd like just to start it. With or without SSH, or something. But just start.
Could you give me a kick here?

I can't open Virtual Box on windows 10 after the Microsoft update on 9/21/2016

I can't open Virtual Box on windows 10 after the Microsoft automatic update on 9/21/2016.
I get this error with vagrant up:
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'scotch/box' is up to date...
==> default: Clearing any previously set forwarded ports...
==> 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 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'aborted' state. Please verify everything is configured
properly and try again.
If the provider you're using has a GUI that comes with it,
it is often helpful to open that and watch the machine, since the
GUI often has more helpful error messages than Vagrant can retrieve.
For example, if you're using VirtualBox, run `vagrant up` while the
VirtualBox GUI is open.
The primary issue for this error is that the provider you're using
is not properly configured. This is very rarely a Vagrant issue.
Trying to start VM with the windows app and it does nothing. No errors, no VM
Does anyone else have this problem?
Is there a way to update VM on windows with re-installing?
This worked for me, finally, though I don't think it is a long term solution.
uninstall virtual box
delete .vagrant directory (..../vagrant/.vagrant)
re-install virtual box version 5.0.20 (this is an older version)
vagrant up

vagrant up timing out on Windows 10

I'm trying to boot up a vagrant instance but it seems to hang at the default: SSH auth method: private key part no matter what I do. I'm new to vagrant so it's entirely possible that there's something I haven't done but should have.
System info:
Windows 10 build 10586.420
Vagrant 1.8.4
VirtualBox 5.0.22 r108108
vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'hashicorp/precise64' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 22 (guest) => 2222 (host) (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
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.
If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.
If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.
I had a look around for similar issues and people have suggested making sure Hyper-V is disabled (which it is) and enabling the virtualbox GUI to see if there are any other errors that aren't being put in the command line.
When I open the virtualbox GUI, I see a username/password prompt (see below):
I've tried entering the default vagrant username/passwords and these work but the vagrant up script still hangs and eventually crashes.
Any help would be much appreciated.
Thanks.

Set up a test kitchen cookbook recipe to generate chef server inside vagrant

I'm experimenting with chef and test kitchen.
The problem I'm facing is as follows.
I'm using arch linux and I couldn't get chef installed on my machine, so I decided to use a centos7 box for a working vm to do so.
My goal is to have enterprise chef server created using a cookbook by test kitchen and have both machines (server and the working vm) accessible on the same network one depending on the other. So yeah, it's a nested setup.
If anyone has a better idea, I'm open to different suggestions.
For the working vm, I used this box:
https://github.com/holms/vagrant-centos7-box/releases/download/7.1.1503.001/CentOS-7.1.1503-x86_64-netboot.box
Here's the contents of my Vagrant file:
Vagrant.configure(2) do |config|
config.vm.box = "chef-repo"
config.vm.network "public_network"
end
So really basic stuff ...
I successfully installed chef and test kitchen on that machine and life was good.
The problem now is using test kitchen to install chef server from here:
https://downloads.chef.io/chef-server/
I created a really simple config with test kitchen that resembles the following:
recipes/default.rb
package_url = node['enterprise-chef']['url']
package_name = ::File.basename(package_url)
package_local_path = "#{Chef::Config[:file_cache_path]}/#{package_name}"
# omnibus_package is remote (i.e., a URL) let's download it
remote_file package_local_path do
source package_url
end
package package_local_path
# reconfigure the installation
execute 'private-chef-ctl reconfigure'
...and attributes/default.rb
default['enterprise-chef']['url'] = 'https://web-dl.packagecloud.io/chef/stable/packages/el/7/chef-server-core-12.1.0-1.el7.x86_64.rpm'
After which I run $ kitchen converge and it fails miserably with this:
[vagrant#localhost enterprise-chef]$ kitchen converge
-----> Starting Kitchen (v1.4.0)
-----> Creating <default-centos-65>...
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'opscode-centos-6.5'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: kitchen-enterprise-chef-default-centos-65_default_1436040993946_29931
==> default: Clearing any previously set network interfaces...
==> default: Available bridged network interfaces:
1) eth0
2) eth1
==> default: When choosing an interface, it is usually the one that is
==> default: being used to connect to the internet.
Vagrant is attempting to interface with the UI in a way that requires
a TTY. Most actions in Vagrant that require a TTY have configuration
switches to disable this requirement. Please do that or run Vagrant
with TTY.
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Failed to complete #create action: [Expected process to exit with [0], but received '1'
---- Begin output of vagrant up --no-provision --provider virtualbox ----
STDOUT: Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'opscode-centos-6.5'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: kitchen-enterprise-chef-default-centos-65_default_1436040993946_29931
==> default: Clearing any previously set network interfaces...
==> default: Available bridged network interfaces:
1) eth0
2) eth1
==> default: When choosing an interface, it is usually the one that is
==> default: being used to connect to the internet.
STDERR: Vagrant is attempting to interface with the UI in a way that requires
a TTY. Most actions in Vagrant that require a TTY have configuration
switches to disable this requirement. Please do that or run Vagrant
with TTY.
---- End output of vagrant up --no-provision --provider virtualbox ----
Ran vagrant up --no-provision --provider virtualbox returned 1]
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration
[vagrant#localhost enterprise-chef]$
I'm currently trying to figure out the problem by manually changing the Vagrantfile located in .kitchen/kitchen-vagrant/kitchen-enterprise-chef-default-centos-65:
Vagrant.configure("2") do |c|
c.berkshelf.enabled = false if Vagrant.has_plugin?("vagrant-berkshelf")
c.vm.box = "opscode-centos-6.5"
c.vm.box_url = "https://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.5_chef-provisionerless.box"
c.vm.network :public_network
c.vm.synced_folder ".", "/vagrant", disabled: true
c.vm.provider :virtualbox do |p|
end
end
so far, I'm getting this error:
[vagrant#localhost kitchen-enterprise-chef-default-centos-65]$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Available bridged network interfaces:
1) eth0
2) eth1
==> default: When choosing an interface, it is usually the one that is
==> default: being used to connect to the internet.
default: Which interface should the network bridge to? 1
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
default: Adapter 2: bridged
==> 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: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
^C==> default: Waiting for cleanup before exiting...
Vagrant exited after cleanup due to external interrupt.
$
The default: Warning: Connection timeout. Retrying... goes indefinitely and I'm forced to stop it.
But the machine seems to be running, only inaccessible to the first vagrant instance.
[vagrant#localhost kitchen-enterprise-chef-default-centos-65]$ vagrant status
Current machine states:
default running (virtualbox)
The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.
[vagrant#localhost kitchen-enterprise-chef-default-centos-65]$
My guess is that something is terrible wrong with the network configuration.
Any ideas or some feedback around my setup are very much welcome.
Thank you.
I'd suggest you just use chef-zero provisioner for foodcritic.
provisioner:
name: chef_zero
data_bags_path: /some/path
...
That will spin up a temporary chef-zero server on the host box, and make it available to the foodcritic run. This also saves you the major overhead of a second server running. The only setback I know of here is if you happen to need multiple nodes under test at the same time. I'm not entirely sure how the plugin would handle that. Either it would share one Chef-zero (which could be good or bad), create one per test suite (again, good or bad, depending on what you actually want), or it may just crash.
The chef server cookbook is already setup to run test kitchen:
git clone https://github.com/chef-cookbooks/chef-server.git
cd chef-server
kitchen converge default-centos-71
It leverages vagrant to setup a local IP address for the chef server to run. Would be interesting if this works within your virtual machine (nested virtualization).
An alternate approach is to run your test VMs on Digital ocean leveraging the cloud kitchen file:
https://github.com/chef-cookbooks/chef-server/blob/master/.kitchen.cloud.yml

Resources