Chef Test Kitchen Timeout during vagrant up - vagrant

While working with Chef, Kitchen, Vagrant and Virtual Box today... I encountered a bizarre issue when attempting to use the bento boxes hosted by Hashicorp (https://atlas.hashicorp.com/bento/) to do some Chef cookbook development/testing.
While spinning up a new cookbook, I wanted to test some newer versions of CentOS 7.2 and Ubuntu 16.04 which are not currently live in our environment. I turned to hashicorp's bento boxes to pull them down into my .kitchen.yml config.
.kitchen.yml
---
driver:
name: vagrant
provisioner:
name: chef_zero
customize:
memory: 1024
platforms:
- name: ubuntu-16.04
suites:
- name: default
run_list:
- recipe[sandbox::default]
attributes:
Used chef generate cookbook to create a new cookbook and as you can see above, was using a very vanilla kitchen config to get things started.
When running kitchen create I kept encountering the following error as an SSH Timeout when provisioning the VM using Vagrant and Virtual Box.
ERROR:
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.
When observing the Virtual Box VM Console, I noted the following (see screen shot below)...
A start job is running for Raise network interfaces (2 min 39s / 5min 3s)
Observing that Vagrant would timeout prior to the start job completing... I attempted to resolve by increasing the boot_timeout from a default of 300 seconds to 600 seconds in my .kitchen.yml
However, further testing proved that this did not resolve the issue even though the VM would successfully initialize after 5mins 3s... Kitchen / Vagrant were unable to SSH to the Host and the failure and the Vagrant SSH timeout persisted.

Ultimately, to resolve this issue I upgraded ChefDK, Vagrant, and VirtualBox to the latest versions available.
Experienced the issue with...
Virtual Box 5.0.30 r112061
Vagrant 1.8.6
Chef Development Kit 0.19.6
Resolved the issue by upgrading to...
Virtual Box 5.1.10 r112026
Vagrant 1.9.0
Chef Development Kit Version: 1.0.3
Following the version upgrades, the Vagrant SSH Timeouts disappeared completely and the box was created successfully within a few seconds.
Virtual Box VM Console

Related

Vagrant cannot vagrant up the box packaged from ubuntu xenial64 16.04

I have a custom vagrant box based on the offcial box ubuntu 16.04.
I simplly run like this to get the packaged box.
vagrant init ubuntu/xenial64; vagrant up --provider virtualbox
vagrant up
vagrant ssh # enter the virtual machine and do some custom change on it
vagrant halt
vagrant package --vagrantfile Vagrantfile --output custom_ubuntu1604.box
and then i copy the file custom_ubuntu1604.box to another directory, i use the box like this:
vagrant box add ubuntu1604base custom_ubuntu1604.box
vagrant init ubuntu1604base
vagrant up # at this point the machine will be stopped at "Started Journal Servie"
my new virtualbox machine base on the new packaged box will stop at:
the screenshot
And finally it timed out:
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.
Try to set config.vm.boot_timeout in Vagrantfile more than default e.x.600. From my experience I found out it take a long time at the first time to connecting guest machine.
For example
Vagrant.configure("2") do |config|
config.vm.box = "ubuntu/xenial64"
config.vm.provider "virtualbox"
config.vm.boot_timeout = 600
end

Unable to install basic kubernetes on OSX host under vagrant/virtualbox

I'm attempting get started with kubernetes and do a vagrant/virtualbox install as per http://kubernetes.io/docs/getting-started-guides/binary_release/#download-kubernetes-and-automatically-set-up-a-default-cluster
My commands are:
export KUBERNETES_PROVIDER=vagrant
curl -sS https://get.k8s.io | bash
I get the following errors at the terminal:
master: Vagrant insecure key detected. Vagrant will automatically replace
master: this with a newly generated keypair for better security.
master:
master: Inserting generated public key within guest...
master: Removing insecure key from the guest if it's present...
master: Key inserted! Disconnecting and reconnecting using new SSH key...
master: Warning: Authentication failure. Retrying...
<snip>
master: Warning: Authentication failure. Retrying...
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.
The script then exits without completing kubernetes "master" set up and without setting up any nodes.
I am able to vagrant ssh master, but need to manually enter the default "vagrant" password.
I am running OSX 10.11.6 (15G31). I am running recent versions of virtualbox (5.0.26 r108824) and vagrant (1.8.5).
These kubernetes "getting started" instructions appear to be downloading the latest kubernetes version (1.3.4).
Because I had older virtualbox and vagrant versions installed, I made sure to completely uninstall and reinstall both, as per:
https://www.virtualbox.org/manual/ch02.html#idm871
https://www.vagrantup.com/docs/installation/uninstallation.html
I assume there is something going wrong with ssh somewhere, though given that these are the published "getting started" instructions and I am using fresh installs of all components, I am surprised that this is not working right out of the box.
Take a look at https://github.com/kubernetes/minikube. It's an official Kubernetes project intended to simplify this exact use case. I've been using it for a few weeks and it works great.
The easiest way to run kubernetes on OSX, I think, is by using Kube-Solo or Kube-Cluster.
Please check this repo:
https://github.com/TheNewNormal/kube-cluster-osx
Note: for me is only working well with the CoreOS stable release.

Vagrant access guest machine from host (windows)

I installed a vagrant virtual machine in Windows, it's working fine, I am trying to connect to the guest machine from windows, but as soon as I uncomment some thing in Vagrantfile like :
config.vm.network "private_network", ip: "192.168.33.10"
OR
config.vm.network "public_network"
when reloading vagrant, I got this error :
The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'poweroff' 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.
I know this does not make sense but I just open VirtualBox and with right-click goes to Settings of created vagrant machine image and diable Audio and it is working after save and run vagrant up
I never encountered that error personally, having never used vagrant on windows. This issue has been discussed here.

How create an ssh connection from vagrant to a specific virtual machine? Can I create a connection to a VM installed on WMware?

I am absolutly new in Vagrant and in Apache Storm.
I am following an online course where show the following situation.
1) There is an Ubuntu virtual machine installed on Virtual Box
2) On the physic machine (the same where is installed Virtual Box and that run the Ubuntu VM) it is installed Vagrant
Ok, from the physic machine, it log into the virtual machine using this statment:
vagrant ssh
and show that it is created a connection to the installed Ubuntu VM.
Here the first doubt: how it know what is the exact virtualized system? What happen if I have installed more than one VM on Virtual Box (with the previous command it is not specified to what installed VM have to be connected)
Another doubt is: I don't use Virtual Box but I use WMware workstation? How can I use the vagrand ssh command to create a connection to a specific VM installed on my WMware workstation?
I'd try to answer a few points from your question -
First, in vagrant language the physic machine will be the host and the VM is called the guest (or guest VM)
Vagrant knows how to connect to the VM it did create as it maintains the Id of the created VM into a .vagrant directory where you have initialized the Vagrantfile.
You can run vagrant global-status and you will have an output with all the VMs that vagrant managed along with the Id, Name and Provider information.
The provider can be VirtualBox or VMWare or anything else. The same in the .vagrant directory you will have subdirectory for the provider (e.g. a directory .vagrant/machines/default/virtualbox or .vagrant/machines/default/vmware_xxx) by default vagrant will start the Virtualbox provider but you can specify the --provider=XXX option when setting up the VM for the 1st time and then vagrant will create the VM for this specific provider and further command on this VM (ssh, reload ...) will work on this specific provider.

Kitchen Converge for windows 7 box failing with boot timeout

I'm currently using a test kitchen to try and converge a Windows 7 machine with VMware Fusion as the provisioner to eventually deploy a chef cookbook. Every time I run a kitchen converge the process hangs on "Waiting for machine to boot. This may take a few minutes" and then fails due to a timeout. When I open Fusion I see the following:
Does anyone know what's happening? I've been struggling for a while to get this VM converged and haven't been able to get the VM up and running successfully to the point where I can deploy my cookbooks and I'm out of ideas.
My .kitchen.yml:
---
driver:
name: vagrant
ssh:
insert_key: false
customize:
cpus: 2
memory: 4096
transport:
name: winrm
provisioner:
name: chef_solo
platforms:
- name: windows-7
driver_config:
box: opentable/win-7-professional-i386-nocm
suites:
- name: default
run_list:
- recipe[my_recipe]
attributes:
I tried finding a sane Windows 7 Vagrant box for a Puppet presentation awhile ago and ran into similar issues. I had to run a powershell script to install Puppet before anything. Even still, I ran into similar issues, and had to do some extra work.
I was using the designerror box from Atlas. Perhaps my notes could assist you getting your environment up and running. It's Puppet, but a similar (easier?) process probably is needed for Chef: https://github.com/stark525/itbestprac-pres/tree/master/vagrant
Windows 7 boxes are typically home grown and owned, so you should probably build your own box if the project warrants the commitment. Ultimately, Windows provides a number of challenges to publicly distributable Vagrant boxes.
It appears that all of the VMware Windows boxes on Altas are misconfigured in one way or another. I manually built my own box (amarkon/windows-7-ult-n-x64) which now works correctly.

Resources