Managing A Vagrant Environment's Power State

Now that we’ve created our Vagrantfile we can discuss how we manage the power state of our development environment using Vagrant commands.

Vagrant Up

Several Vagrant commands allow us to manage the power state of our development environment. The most important of which is the vagrant up command.

Vagrant up will power on our VM and run through the following steps.

  • Download the box (if it hasn’t been used on the system)
  • Import the box into our provider (if it hasn’t already)
  • Power on the VM (always)
  • Run any scripts we wrote to setup our development environment.

The last step happens automatically if the box was imported during this run of vagrant up but can be manually run again later (we’ll discuss this in a future article).

Let’s see what happens if we do it now.

our-awesome-project % vagrant up                           
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'generic/ubuntu2004' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'generic/ubuntu2004'
    default: URL: https://vagrantcloud.com/generic/ubuntu2004
==> default: Adding box 'generic/ubuntu2004' (v3.1.22) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/generic/boxes/ubuntu2004/versions/3.1.22/providers/virtualbox.box
Download redirected to host: vagrantcloud-files-production.s3.amazonaws.com
    default: Calculating and comparing box checksum...
==> default: Successfully added box 'generic/ubuntu2004' (v3.1.22) for 'virtualbox'!
==> default: Importing base box 'generic/ubuntu2004'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'generic/ubuntu2004' version '3.1.22' is up to date...
==> default: Setting the name of the VM: our-awesome-project_default_1610932671808_5447
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    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: 
    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 it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...

If we look in VirtualBox at this point we can see that our VM has been created and is running. By default the name is based on the directory and the name of the VM inside our Vagrantfile.

Virtual Box after a Vagrant Up

Vagrant Halt

Now that we’ve powered on our VM we need to be able to turn it off. This is done using the vagrant halt command.

our-awesome-project % vagrant halt
==> default: Attempting graceful shutdown of VM...

If we look in VirtualBox at this point we can see that our VM is still listed but is no longer running.

Virtual Box after a Vagrant Halt

We can run vagrant up again to bring it back to a powered up state.

Vagrant Reload

There will be occasions where we want to restart our development environment so it can pickup changes in our Vagrantfile or just because it’s acting finicky. Vagrant reload bundles up running vagrant halt and then a vagrant up.

our-awesome-project % vagrant reload
==> default: Attempting graceful shutdown of VM...
==> default: Checking if box 'generic/ubuntu2004' version '3.1.22' 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 (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: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> 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 Suspend/Resume

Vagrant halt completely shuts our development environment off. This causes us to have to completely start up the VMs the next time we need to use it and we lose our place in our work. By using vagrant suspend we can cause the VMs to be suspended so we can quickly get them back up and running the next time we need them. Vagrant suspend causes the content of the RAM inside our VMs to be saved to our computer’s drive.

our-awesome-project % vagrant suspend
==> default: Saving VM state and suspending execution...

If we look in VirtualBox at this point we can see that our VM is listed in a “Saved” state.

Virtual Box after a Vagrant Suspend

Then when we’re ready to start using our VM we can use vagrant resume or vagrant up to turn it back on. The difference between the two is that resume just wakes up the VM while vagrant up runs config checks to see if our box has a newer version.

our-awesome-project % vagrant resume
==> default: Resuming suspended VM...
==> 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: Machine booted and ready!
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.

In our next article we’ll discuss how to reset our Vagrant environment.