3

I used to create a box for a workshop I am running, and packaged in the box via the vagrantfile_template directive in the Vagrant post-processor as shown:

...
"post-processors": [{
  "type": "vagrant",
  "vagrantfile_template": "vagrantfile_templates/workshop",
  "compression_level": "{{user `compression_level`}}",
  "output": "fedora-22-x86_64.box"
}],
...

The contents of the resulting .box are:

% tar -tf workshop.box
Vagrantfile
box.ovf
metadata.json
packer-fedora-22-x86_64-disk1.vmdk

The contents of Vagrantfile in the box seem OK, and include the contents of the vagrantfile_template specified in the packer configuration. Note that this Vagrantfile defines two VMs named client and server:

% tar -O -xf freeipa-workshop.box Vagrantfile

# The contents below were provided by the Packer Vagrant post-processor

Vagrant.configure("2") do |config|
  config.vm.base_mac = "0800278AF3E8"
end


# The contents below (if any) are custom contents provided by the
# Packer template during image build.
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|

  config.vm.box = "workshop"
  config.vm.synced_folder ".", "/vagrant", disabled: true

  config.vm.define "server" do |server|
    server.vm.network "private_network", ip: "192.168.33.10"
    server.vm.hostname = "server.ipademo.local"
  end

  config.vm.define "client" do |client|
    client.vm.network "private_network", ip: "192.168.33.20"
    client.vm.hostname = "client.ipademo.local"
  end

end

I added the box to vagrant with the name workshop:

% vagrant box add --name workshop workshop.box 
==> box: Adding box 'workshop' (v0) for provider: 
    box: Downloading: file:///.../workshop.box
==> box: Successfully added box 'workshop' (v0) for 'virtualbox'!
% vagrant box list
workshop                  (virtualbox, 0)

Problem description

When I execute vagrant init workshop and then vagrant up, the Vagrantfile included in the box is not applied:

% vagrant init workshop
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
% cat Vagrantfile 
# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure(2) do |config|
  # The most common configuration options are documented and commented below.
  # For a complete reference, please see the online documentation at
  # https://docs.vagrantup.com.

  # Every Vagrant development environment requires a box. You can search for
  # boxes at https://atlas.hashicorp.com/search.
  config.vm.box = "workshop"

  ... and so on (the rest of the default Vagrantfile)

% vagrant up --provider virtualbox
Bringing machine 'default' up with 'virtualbox' provider...
...

Whoa! Why did it bring up default? According to the Vagrantfile docs the Vagrantfile packaged with the box should be used, and other Vagrantfiles including from the current directory should be merged into it. But this does not seem to be the case.

Vagrant 1.7.2 is the version in use.

I would like workshop participants to be able to bring up the VMs defined in the Vagrantfile included in the box, without supplying that Vagrantfile out of band (in order to minimise dependencies). Have I missed something important?

frasertweedale
  • 5,424
  • 3
  • 26
  • 38
  • Is your `/vagrant` folder disabled too so it has been ignored from the template ? or only the multi machine part has been ignored ? do you really have `Vagrant.configure("2") do |config|` twice in the Vagrantfile can you try to merge into one – Frederic Henri Oct 20 '15 at 11:53

1 Answers1

0

As all of us know, Vagrant loads and merges multiple Vagrantfiles in a pre-determined order outlined here (in the same section they also point out that multiple Vagrant.configure blocks are also OK).

I was experiencing the same very same issue when Vagrant would not pick up the config.vm.communicator = "winrm" configuration that was bundled in the .box using vagrantfile_template.

However, by Using vagrant --debug I noticed that Vagrant appeared to have cached the bundled Vagrantfile from a previous build of the same box:

INFO loader: Set :"26224240_win7sp1_x64_virtualbox" = ["#<Pathname:/home/thomas/.vagrant.d/boxes/win7sp1_x64/0/virtualbox/Vagrantfile>"]

One would think that vagrant destroy would remove the associated files in vagrant.d but it does not, so I was able to resolve the issue by manually removing ~/.vagrant.d/boxes/win7sp1_x64.

I confirmed that it now was working as intended by seeing that WinRM was indeed being used:

==> default: Waiting for machine to boot. This may take a few minutes...
    default: WinRM address: 127.0.0.1:55985
    default: WinRM username: vagrant
    default: WinRM execution_time_limit: PT2H
    default: WinRM transport: negotiate
==> default: Machine booted and ready!

Even though the Vagrantfile in the initialized directory did not have that configuration:

Vagrant.configure("2") do |config|
    config.vm.box = "win7sp1_x64"
    config.vm.box_url = "/media/data/VagrantBaseBoxes/win7sp1_x64/win7sp1_x64-virtualbox.box"
end

TL;DR:

Make sure no "old" Vagrantfiles are present in vagrant.d that may overwrite what's configured in the 'packer-ed box (see "load order and merging" in the link above).

FEL
  • 39
  • 6
  • Also, I noticed some issues when testing inside a subdir of a location that contained a Vagrantfile. My advice would be to test in a subdir of /tmp to avoid any such trouble – Olivier Berger Aug 10 '22 at 10:34