Vagrant: "To update to version 'X', destroy and recreate your machine"

[RohanTalip]

Vagrant version

$ vagrant --version
Vagrant 2.2.2

Host operating system

MacOS High Sierra, version 10.13.6

Guest operating system

ubuntu/bionic64

Vagrantfile

Here's a representative Vagrantfile:

required_plugins = %w(vagrant-vbguest)
plugins_to_install = required_plugins.select { |plugin| not Vagrant.has_plugin? plugin }
if not plugins_to_install.empty?
  puts "Installing plugins: #{plugins_to_install.join(' ')}"
  if system "vagrant plugin install #{plugins_to_install.join(' ')}"
    exec "vagrant #{ARGV.join(' ')}"
  else
    abort "Installation of one or more plugins has failed. Aborting."
  end
end

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/bionic64"

  config.vm.network "forwarded_port", guest: 8000, host: 8000, host_ip: "127.0.0.1"

  config.vm.synced_folder "..", "/project"

  config.vm.provider "virtualbox" do |vb|
    vb.memory = "2048"
  end
end

box_meta

This is what is currently in my box_meta file:

$ cat .vagrant/machines/default/virtualbox/box_meta
{"name":"ubuntu/bionic64","version":"20181112.0.0","provider":"virtualbox","directory":"boxes/ubuntu-VAGRANTSLASH-bionic64/20181112.0.0/virtualbox"}

Debug output

The debug output for vagrant box outdated and vagrant up can be found here, hopefully sanitised sufficiently (please note that there are 2 files in the gist) :
https://gist.github.com/RohanTalip/be65d3b6ee7fa2ef53bb0df0aed01efc

Expected behavior

After running vagrant box update, I would have expected that my virtual machine would have been updated to the latest box.

Actual behavior

After running vagrant box update, the latest version of the box appears to have been added, but when I run vagrant box outdated or vagrant up, a message appears indicating that a new version of the box is available but that my Vagrant machine is running against an older version and that to update to the newer version, I need to destroy and recreate my machine. This seems new, although the text for that message appears to have been there for almost 5 years -- it was checked in on 2014-01-24).

Is this expected? I haven't seen this message until recently.

Why is it necessary now to destroy and recreate my machine? Why wasn't it necessary to do this the many times I previously ran vagrant box update followed by vagrant up?

Steps to reproduce

(Some non-essential details are removed or changed below.)

$ vagrant box outdated
Checking if box 'ubuntu/bionic64' is up to date...
A newer version of the box 'ubuntu/bionic64' for provider 'virtualbox' is
available! You currently have version '20181112.0.0'. The latest is version
'20181214.0.0'. Run `vagrant box update` to update.

$ vagrant box update
==> default: Checking for updates to 'ubuntu/bionic64'
    default: Latest installed version: 20181112.0.0
    default: Version constraints: 
    default: Provider: virtualbox
==> default: Updating 'ubuntu/bionic64' with provider 'virtualbox' from version
==> default: '20181112.0.0' to '20181214.0.0'...
==> default: Loading metadata for box 'https://vagrantcloud.com/ubuntu/bionic64'
==> default: Adding box 'ubuntu/bionic64' (v20181214.0.0) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/ubuntu/boxes/bionic64/versions/20181214.0.0/providers/virtualbox.box
==> default: Box download is resuming from prior download progress
    default: Download redirected to host: cloud-images.ubuntu.com
==> default: Successfully added box 'ubuntu/bionic64' (v20181214.0.0) for 'virtualbox'!

$ vagrant box outdated
Checking if box 'ubuntu/bionic64' is up to date...
A newer version of the box 'ubuntu/bionic64' is available and already
installed, but your Vagrant machine is running against
version '20181112.0.0'. To update to version '20181214.0.0',
destroy and recreate your machine.

$ cat .vagrant/machines/default/virtualbox/box_meta
{"name":"ubuntu/bionic64","version":"20181112.0.0","provider":"virtualbox","directory":"boxes/ubuntu-VAGRANTSLASH-bionic64/20181112.0.0/virtualbox"}

$ env VAGRANT_LOG=debug vagrant box outdated >& /tmp/vagrant.box.outdated.log

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: This machine used to live in /Users/rohantalip/dev/gitwork/xyz-server/vagrant but it's now at /Users/rohantalip/dev/gitwork/xyz/xyz-server/vagrant.
==> default: Depending on your current provider you may need to change the name of
==> default: the machine to run it as a different machine.
==> default: Checking if box 'ubuntu/bionic64' is up to date...
==> default: A newer version of the box 'ubuntu/bionic64' is available and already
==> default: installed, but your Vagrant machine is running against
==> default: version '20181112.0.0'. To update to version '20181214.0.0',
==> default: destroy and recreate your machine.
==> default: Clearing any previously set forwarded ports...
==> default: Vagrant has detected a configuration issue which exposes a
==> default: vulnerability with the installed version of VirtualBox. The
==> default: current guest is configured to use an E1000 NIC type for a
==> default: network adapter which is vulnerable in this version of VirtualBox.
==> default: Ensure the guest is trusted to use this configuration or update
==> default: the NIC type using one of the methods below:
==> default: 
==> default:   https://www.vagrantup.com/docs/virtualbox/configuration.html#default-nic-type
==> default:   https://www.vagrantup.com/docs/virtualbox/networking.html#virtualbox-nic-type
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 8000 (guest) => 8000 (host) (adapter 1)
    default: 22 (guest) => 2222 (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:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection reset. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
==> default: Machine booted and ready!
[default] GuestAdditions 5.2.20 running --- OK.
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
    default: /project => /Users/rohantalip/dev/gitwork/xyz/xyz-server
    default: /vagrant => /Users/rohantalip/dev/gitwork/xyz/xyz-server/vagrant
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.

$ vagrant halt
==> default: Attempting graceful shutdown of VM...

$ env VAGRANT_LOG=debug vagrant up >& /tmp/vagrant.up.log

References

I suspect there may still be issues with the solution to GH-10338.

[chrisroberts]

Hi there,

This behavior is not new and has not changed in the latest release of Vagrant. A new version of a box being locally available will not result in a guest being "upgraded" to that new version. This is because that would require destroying the guest which would be unexpected, and most likely unacceptable, in generally all cases.

The wording provided by the vagrant box outdated command may have changed depending on how/if the box_version configuration option was used. The issue that you have linked to forced is simply forcing the box version to match what the existing guest is currently using. It has not changed the behavior of updating boxes and you will always have to destroy and re-up a guest to start using a new version of a box.

Cheers!

[RohanTalip]

@chrisroberts, thanks for the info. I guess that all this time I thought I was updating my box, I really wasn't. Huh.

I think I missed the relevant notice/warning in the vagrant box update documentation. Also, some recent change may have re-exposed the warning message when running vagrant box outdated or vagrant up after a vagrant box update on the command line.

Anyhow, thanks.

[ddelrio1986]

This whole time I always thought I was updating my box as well. Guess I was downloading new versions of boxes but not recreating my boxes to use those new versions. So much time I've wasted. :'(

Thanks for the info @chrisroberts!

[RohanTalip]

FYI, running vagrant box update, vagrant box prune (and answering yes to remove any older boxes that are still being used) and then vagrant up will use the most recent box version that was downloaded. This was confirmed with the new version number that is displayed in the version check when running vagrant up.

So, I was actually updating my boxes, provided that I also pruned the old versions.

This may not be ideal in the general case (e.g. some data in the file system used by the virtual machine might not match the new version of the box / operating system), but in practice I haven't noticed any issues.

[LC43]

@RohanTalip is right. Its just a matter of pruning old boxes.

The wording in the initial message is a bit misleading, if not plain wrong. Maybe it can be refined.
A person doesn't have to destroy the machine! Just update box, prune old ones, and reload.

[bzkn]

My box is stuck on 20181103 version. If I run the vagrant box prune command, it will delete any older (and newer versions, i.e. 20190429) and leave me with 20181103. Running vagrant box update only downloads the new box and next time I do vagrant up I still get a message that I'm using an older box. I used to delete older boxes manually but this behavior appeared after I used vagrant box prune for the first time.

Does this message perhaps imply that if you're stuck in this issue, your only recourse is to destroy and rebuild?

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.