chef on virtualbox. guest is downloading very slowly from host - download

I am using vagrant and chef to build a VM.
Host: OSX 10.9.5
audrey:ubuntu2 jluc$ chef -v
Chef Development Kit Version: 0.10.0
chef-client version: 12.5.1
berks version: 4.0.1
kitchen version: 1.4.2
audrey:ubuntu2 jluc$ vagrant -v
Vagrant 1.8.1
audrey:ubuntu2 jluc$ vagrant plugin list
vagrant-berkshelf (4.1.0)
vagrant-omnibus (1.4.1)
vagrant-share (1.1.5, system)
Virtualbox: 5, but same on 4 previously.
Guest: Ubuntu 14.04
Background: I am using alien to install Oracle rpm. However, you can't just point the client to a url or package somewhere, you need to download the rpms from Oracle, accept conditions and then make the files available to your client install. There are 2 rpms, one 30MB, one 640KB.
I am doing this by launching a http server on the host, on port 9003.
Problem:
The download/remote_file time, within the chef run, is anywhere from 5-20 minutes, while I can wget/curl them from within the guest in 5-15 seconds.
Details:
The following chef code deals with those files:
ip = node[:network][:default_gateway]
simplehttp_port=node[:basedjango][:port_host_fileserver]
fn_basic = "oracle-instantclient12.1-basiclite-12.1.0.2.0-1.x86_64.rpm"
execute 'download_basic' do
cwd "/tmp"
command "wget http://#{ip}:#{simplehttp_port}/#{fn_basic} "
not_if do ::File.exists?(fnp_basic) end
end
#I have also used this instead, just as slow...
remote_file fnp_basic do
uri = "http://#{ip}:#{simplehttp_port}/#{fn_basic}"
not_if do ::File.exists?(fnp_basic) end
mode '0755'
action :create
end
My problem is that I can vagrant ssh into the guest and wget or curl the file in anything from 5 to 15 seconds. From the chef cookbooks, I am looking at 5-20 minutes each time (there is a condition guard to avoid downloading it if it exists).
==> default: [2016-01-18T11:13:58-08:00] INFO: file[/etc/profile.d/ORACLE_HOME.sh] mode changed to 755
==> default:
==> default: - change mode from '' to '0755'
==> default:
==> default: - change owner from '' to 'root'
==> default:
==> default: - change group from '' to 'root'
==> default:
==> default: (up to date)
==> default: Recipe: basedjango::oracle
==> default:
==> default: * execute[download_basic] action run
!!! 11:13 to 11:28 => 15 minutes here.
==> default: [2016-01-18T11:28:04-08:00] INFO:
execute[download_basic] ran successfully
==> default:
==> default: - execute wget http://10.0.2.2:9003/oracle-instantclient12.1-basiclite-12.1.0.2.0-1.x86_64.rpm
==> default: * execute[install_basic] action run
And here is the same command, executed manually via vagrant ssh. About 2 seconds in this case.
vagrant#vagrant:/tmp$ wget http://10.0.2.2:9003/oracle-instantclient12.1-basiclite-12.1.0.2.0-1.x86_64.rpm
--2016-01-18 11:50:40-- http://10.0.2.2:9003/oracle-instantclient12.1-basiclite-12.1.0.2.0-1.x86_64.rpm
Connecting to 10.0.2.2:9003... connected.
HTTP request sent, awaiting response... 200 OK
Length: 30940809 (30M) [text/html]
Saving to: ‘oracle-instantclient12.1-basiclite-12.1.0.2.0-1.x86_64.rpm’
100%[====================================================================================================================================================================================>] 30,940,809 17.8MB/s in 1.7s
2016-01-18 11:50:41 (17.8 MB/s) - ‘oracle-instantclient12.1-basiclite-12.1.0.2.0-1.x86_64.rpm’ saved [30940809/30940809]
The remote_file resource behaves the same way, so at first I thought it was something wrong with it or the way I use it. The rpms are NOT being served from the Vagrant shared directory, btw.
Any ideas?

I don't know if you haven't already found a solution, but when I had that issue (even downloading from another server) I could 'fix' it by enabling debug output for chef. This magically increased the download speed.
Simply put
config.vm.provion :chef_solo |chef|
chef.log_level = 'debug'
[...]
end

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.

I can't connect to a Vagrant handled VM: `ssh` executable not found in any directories in the %PATH%, but I have it

I am absolutly new in Vagrant and I have the following problem. I am using Windows 8.1.
I have done the following operations:
First I have download this into a folder of my host from github, by this statment:
git clone https://github.com/Udacity/ud381
Then I performed:
vagrant up
that downloaded the Vagrant Box containing the guest VM
and when now I perform the vagrant up command I obtain this message:
C:\Users\Andrea\Documents\workspaces\Real-Time\ud381>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'udacity/ud381' is up to date...
==> default: There was a problem while downloading the metadata for your box
==> default: to check for updates. This is not an error, since it is usually due
==> default: to temporary network problems. This is just a warning. The problem
==> default: encountered was:
==> default:
==> default: Failed connect to atlas.hashicorp.com:443; No error
==> default:
==> default: If you want to check for box updates, verify your network connectio
n
==> default: is valid and try again.
==> 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: 5000 => 5000 (adapter 1)
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: Remote connection disconnect. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
default: /vagrant => C:/Users/Andrea/Documents/workspaces/Real-Time/ud381
==> default: Machine already provisioned. Run `vagrant provision` or use the `--
provision`
==> default: flag to force provisioning. Provisioners marked to run always will
still run.
I think that it is correct but I am not absolutly sure about it because it seems that I have some warning message but it say: default: Machine booted and ready! so I think that it is ok (is it ok?)
Then I try to connect to it by SSH performing the vagrant ssh statment but I obtain this error message:
C:\Users\Andrea\Documents\workspaces\Real-Time\ud381>vagrant ssh
`ssh` executable not found in any directories in the %PATH% variable. Is an
SSH client installed? Try installing Cygwin, MinGW or Git, all of which
contain an SSH client. Or use your favorite SSH client with the following
authentication information shown below:
Host: 127.0.0.1
Port: 2222
Username: vagrant
Private key: C:/Users/Andrea/Documents/workspaces/Real-Time/ud381/.vagrant/machi
nes/default/virtualbox/private_key
Searching on Google I found that to use this statment I need the git path into the PATH environment variable. I check and I have it setted, infact inside the PATH variable I have these 2 values:
C:\HashiCorp\Vagrant\bin;C:\Program Files\Git\bin
the first one is the vagrant path and the second one the Git path.
So this is not the problem. Searching online I also found this StacOverflow discussion:
`ssh` executable not found in any directories in the %PATH%
that send to this link for this kind of problem: https://gist.github.com/haf/2843680
In this link it show how to modify an ssh.rb file into this folder C:\vagrant\vagrant\embedded\lib\ruby\gems\1.9.1\gems\vagrant-1.0.3\lib\vagrant\ssh.rb
The problem is that I have not this folder but something like this:
C:\HashiCorp\Vagrant\embedded\lib\ruby\gems\2.0.0\gems\
and this folder don't contain the *vagrant-1.0.3\lib\vagrant* subfolder (that contain the ssh.rb file) but contain 3 directory respectivelly named rake-0.9.6, rdoc-4.0.0 and test-unit-2.0.0.0 that don't contain the ssh.rb file.
Searching this file I found 2 different version into these folder:
C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.7.4\plugins\kernel_v1\config
and
C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.7.4\plugins\kernel_v2\config
I think that maybe the difference from the tutorial could depend by the fact that it is referred to a very old Vagrant version (it is 4 year old) and I have installed the 1.7.4 version of Vagrant.
So how can I connect in SSH to the VM handled by Vagrant?
The error message
C:\Users\Andrea\Documents\workspaces\Real-Time\ud381>vagrant ssh `ssh`
executable not found in any directories in the %PATH% variable. Is an
SSH client installed?
states that the cli you are currently using (wich is probably cmd or powershell when you are working under windows) could not find an installed ssh client. That means your cli was not able to find a programm that can handle connecting to another server (in this case your vagrantbox) via ssh.
This is a pretty common scenario since windows does not come with an ssh client out of the box (unlike ubuntu or osx).
AFAIK there is no ssh program/command that you can easily install and put into your PATH so that it will work with cmd.
What you probably want to do in this situation is installing a different cli that comes with these features. You have several Options here, they are also stated in the error message:
Try installing Cygwin, MinGW or Git, all of which
contain an SSH client
I recommend you using Git Bash which you probably already have installed on your system since you are using git.
So to perform a vagrant ssh your first step will be starting Git Bash either by executing the program itself (which comes with git, on my system it could be found under: C:\Program Files\Git\git-bash.exe) or by right clicking in a directory listing in Windows Explorer and selecting Git Bash here (this will only work if you checked a certain box upon Git install).
It will open a new cli which works with linux like commands.
You should be able to cd into your vagrant directory and perform a vagrant ssh now.
The solution you linked to in your question no longer seems to work since the path of the ssh client comming with git seems to have changed.
See Ygor Thomaz' comment in the other SO post you found. The PATH path has changed to:
C:\Program Files\Git\usr\bin
..so run this in cmd:
set PATH=%PATH%;C:\Program Files\Git\usr\bin
Related:
How do you update the GIT_SSH environment variable on Windows
https://stackoverflow.com/a/16247703/1869660

Centos7 with private network lost fixed IP

I've a network issue with a centos7 vagrant box.
When I setup a private network, with fixed IP, this one is well binding first, but get lost after some seconds/minutes.
vagrant up
==> default: Forcing shutdown of VM...
==> default: Destroying VM and associated drives...
==> default: Running cleanup tasks for 'shell' provisioner...
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'sfeirbenelux/centos7'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'sfeirbenelux/centos7' is up to date...
==> default: Setting the name of the VM: poc_docker
==> 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: Adapter 2: hostonly
==> default: Forwarding ports...
default: 22 => 2200 (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
default: Warning: Connection timeout. Retrying...
default:
default: Vagrant insecure key detected. Vagrant will automatically replace
default: this with a newly generated keypair for better security.
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if its present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
default: The guest additions on this VM do not match the installed version of
default: VirtualBox! In most cases this is fine, but in rare cases it can
default: prevent things such as shared folders from working properly. If you see
default: shared folder errors, please make sure the guest additions within the
default: virtual machine match the version of VirtualBox you have installed on
default: your host and reload your VM.
default:
default: Guest Additions Version: 5.0.2
default: VirtualBox Version: 4.3
==> default: Setting hostname...
==> default: Configuring and enabling network interfaces...
==> default: Running provisioner: shell...
default: Running: inline script
==> default: net.ipv4.ip_forward = 1
==> default: Setting up swapspace version 1, size = 2097148 KiB
==> default: no label, UUID=170723d8-1782-4915-a877-4d9874ac7396
➜ install git:(master) ✗ ping 192.168.100.20
PING 192.168.100.20 (192.168.100.20): 56 data bytes
64 bytes from 192.168.100.20: icmp_seq=0 ttl=64 time=0.390 ms
64 bytes from 192.168.100.20: icmp_seq=1 ttl=64 time=0.252 ms
64 bytes from 192.168.100.20: icmp_seq=2 ttl=64 time=0.461 ms
^C
--- 192.168.100.20 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.252/0.368/0.461/0.087 ms
➜ install git:(master) ✗ ping 192.168.100.20
PING 192.168.100.20 (192.168.100.20): 56 data bytes
64 bytes from 192.168.100.20: icmp_seq=0 ttl=64 time=0.273 ms
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
With this vagrant file :
vagrant.configure(2) do |config|
config.vm.box = "centos7"
config.vm.hostname = "docker-registry"
config.vm.box_url = "https://github.com/holms/vagrant-centos7-box/releases/download/7.1.1503.001/CentOS-7.1.1503-x86_64-netboot.box"
#config.vm.network "public_network"
config.vm.network "private_network", ip: "192.168.100.20"
#config.vm.synced_folder ".", "/vagrant", type: "nfs"
# VirtualBox
config.vm.provider :virtualbox do |vb|
vb.name = "poc_docker"
vb.memory = 3072
vb.cpus = 2
vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]
end
end
When I connect on the box, it seems that the ip is lost.
sudo /sbin/ifup eth1
Fix the problem temporary, but the IP get losts sometime again.
Rebooting the box (vagrant halt && vagrant up) seem to fix the problem permanently.
I've try to create a custom centos 7 box with Packer ( https://atlas.hashicorp.com/sfeirbenelux/boxes/centos7), and I reproduce the issue too.
I suppose that's a Centos 7 specific issue ?
Do you already have the same problem ? Is there a way to fix this by adding a vagrant command ?
My environment :
OS X Yosemite
➜ ~ vagrant --version
Vagrant 1.7.2
➜ ~ VBoxManage --version
4.3.26r98988
It seems that's a problem due to DHCP configuration ( issue : https://github.com/mitchellh/vagrant/issues/5590 )
the network service doesn't reload NetworkManager, so it will continue to wait for dhcp lease .. and after dhcp timeout, the fixed ip is removed.
Adding a shell provision script with
sudo nmcli connection reload
sudo systemctl restart network.service
Fixes the problem
EDIT:
vagrant 1.7.3+ fixes the bug too ;)
There seems to be a similar issue in newer Vagrant versions (1.9.1).
A pull request that fixes the issue was already merged (not released yet):
https://github.com/mitchellh/vagrant/pull/8148
If you want to apply that fix you can try this (sudo may be required, depending on the file permissions):
Locate you local Vagrant installation (on Fedora it is /opt/vagrant/)
Move to the folder of the vagrant gem:
cd embedded/gems/gems/vagrant-1.9.1
Initialize a new Git Repository and add the GitHub remote:
git init
git remote add origin https://github.com/mitchellh/vagrant.git
git fetch --all
Checkout a new branch and reset it to your current release (e.g. 1.9.1).
If you are unsure if you have local changes do not use --hard and do a git diff / git checkout after the reset:
git checkout -b hotfixes
git reset --hard v1.9.1
Now apply the hotfix:
git cherry-pick 96611341a96d7d19fdade5556a110b22c6add22b
After that a vagrant reload should bring up the local network just fine.
The fix is mentioned in: https://github.com/mitchellh/vagrant/pull/8148
In /opt/vagrant/embedded/gems/gems/vagrant-1.9.1/plugins/guests/redhat/cap/configure_networks.rb,
add /sbin/ifup '#{network[:device]}' right after nmcli c reload || true.

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

Using rsync on windows with vagrant running a CoreOS VM

I am using windows 8.1 Pro pc running vagrant and cygwin's rsync.
I am configuring as such:
config.vm.synced_folder "../sharedFolder", "/vagrant_data", type: "rsync"
And when I execute vagrant up I get the following error:
C:\dev\vagrantBoxes\coreOS>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'yungsang/coreos' 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 => 2222 (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:2222
default: SSH username: core
default: SSH auth method: private key
default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Rsyncing folder: /c/dev/vagrantBoxes/sharedFolder/ => /vagrant_data
There was an error when attempting to rsync a synced folder.
Please inspect the error message below for more info.
Host path: /c/dev/vagrantBoxes/sharedFolder/
Guest path: /vagrant_data
Command: rsync --verbose --archive --delete -z --copy-links --chmod=ugo=rwX --no-perms --no-owner --no-group --rsync-path sudo rsync -e ssh -p 2222 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/d
ev/null -i 'C:/Users/aaron.axisa/.vagrant.d/insecure_private_key' --exclude .vagrant/ /c/dev/vagrantBoxes/sharedFolder/ core#127.0.0.1:/vagrant_data
Error: Warning: Permanently added '[127.0.0.1]:2222' (RSA) to the list of known hosts.
rsync: change_dir "/c/dev/vagrantBoxes/sharedFolder" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at /usr/src/ports/rsync/rsync-3.0.9-1/src/rsync-3.0.9/main.c(1052) [sender=3.0.9]
I assume it is an issue with how it is changing the directory path to /c/dev rather than C:\dev
like I commented in the github-issue, following line in your Vagrantfile will most certainly fix your problem
ENV["VAGRANT_DETECTED_OS"] = ENV["VAGRANT_DETECTED_OS"].to_s + " cygwin"
since this is local in your Vagrantfile, the source-files can be kept untouched
workaround: just ln -s /cygdrive/c/ /c on cygwin terminal
There is a hacky way to fix this (worked for me anyway) where you have to change
hostpath = Vagrant::Util::Platform.cygwin_path(hostpath)
to
hostpath = "/cygdrive" + Vagrant::Util::Platform.cygwin_path(hostpath)
on line 43 in C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-[VERSION]\plugins\synced_folders\rsync\helper.rb
It's different for 1.5.x, you can read this thread here about it: https://github.com/mitchellh/vagrant/issues/3230
I will, however, be the first to admit that editing the core is far from ideal.
From my testing, if you are using cygwin, use the solution by #osroot25 .
If you are using cwRsync and do not have cygwin, there is no workaround using Vagrant except editing the source code as #Andrew Myers details. Tested using Vagrant v1.6.5.
My workaround that works for me is to bypass Vagrant altogether and use cwRsync directly. This works for me because I am syncing a folder that hardly ever changes. I might change it quite a few times in one day (so I have to remember step 2 below each time), but I then go weeks (or months) without any changes. Remember that to use cwRsync you have to edit and use the cwrsync.cmd script. Attempting to access the rsync.exe command directly or by adding it to your path will fail. Step 1: I added the following line to the end of cwrsync.cmd (in the installed folder):
rsync -re "ssh -p 2222" /cygdrive/b/VCS/packages/ vagrant#localhost:packages --exclude ".git/"
Step 2: I have a separate cmd window open that I run the cwrsync.cmd using the full path. Then if I need to sync changes onto the VM, I activate that window, up-arrow, return and updating is instant!
Modifying ENV to set cygwin fix by #osroot25 doesn't work with cwRsync because when you force cygwin detection, the "vagrant ssh" command will not work because it requires the cygpath command in cygwin, which you won't have, so you cannot ssh into the VM. Well you can if you use the ssh command directly with all the right options.

Resources