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.
Related
for some time I have tried to run vagrant and it worked well with ansible. However the images work completely different from images created manually. Even it looks like ssh, network, shared folders etc are slightly different configured and can only be used in the vagrant tool chain.
So I would like to only have ansible and virtualbox on the host and use the same ssh connection for ansible as for the user
Any hints, roles, examples on how to do that (google is not a help here)
here is a short example (so maybe it is possible) if ansible could wait for the vms to be started !?
---
- hosts: all
tasks:
- name: list VMs
shell: VBoxManage list vms
args:
executable: /bin/bash
I am running vagrant version,
vagrant -v
Vagrant 1.9.3
vagrant plugin list
vagrant-butcher (2.2.1)
vagrant-cachier (1.2.1)
vagrant-omnibus (1.5.0)
vagrant-share (1.1.7, system)
vagrant-vbguest (0.13.0)
When I start a vagrant VM, windows 2012r2,
I get "Renaming the Windows guest failed. Most often this is because you've specified a FQDN instead of just a host name."
It used to work before on the same host(centos7, with Virtualbox) with version 1.4.
If you are (like me) experiencing this with Kitchen, in your .kitchen.yml, in the platform section, you can't have "name: mwrock/Windows2012R2". Instead, name it something like "windows2012R2" and, in platform's "driver_config" section, specify "box: mwrock/Windows2012R2".
Another way you can resolve this issue is by setting the vm_hostname attribute to false like this:
platforms:
- name: BPA-TEST
driver_config:
username: Tester
password: [PASSWORD]
vm_hostname: false
driver:
port: 55985
customize:
memory: 4048
https://github.com/test-kitchen/kitchen-vagrant
vm_hostname Sets the internal hostname for the instance. This is not used when connecting to the Vagrant virtual machine.
To prevent this value from being rendered in the default Vagrantfile,
you can set this value to false.
The default will be computed from the name of the instance. For
example, the instance was called "default-fuzz-9" will produce a
default vm_hostname value of "default-fuzz-9". For Windows-based
platforms, a default of nil is used to save on boot time and potential
rebooting.
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
To run kitchen converge and set up my test kitchen vagrant instance, such as in this guide, I have noticed that I must first create a $COOKBOOK_ROOT_DIR/.kitchen/default-centos-72.yml file. After the file has been created with kitchen converge I must then control + c edit the file to include the password: vagrant line and then run kitchen converge again. In the end the file will look something like this:
---
hostname: 127.0.0.1
port: '2222'
username: vagrant
password: vagrant
ssh_key: "$COOKBOOK_ROOT_DIR/.kitchen/kitchen-vagrant/kitchen-$COOKBOOK_NAME-default-centos-72/.vagrant/machines/default/virtualbox/private_key"
last_action: converge
How can I have chef kitchen automatically know to use password: vagrant before running kitchen converge? Or better yet how can I have chef create test instances without any ssh passwords?
Yep #coderanger got it. I needed to downgrade to vagrant 1.8.4 and virtualbox 4.3.4 because virtualbox version 5+ doesnt work with vagrant 1.8.4.
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.