In the last post, we got our VM up and running. Now we need to configure a hostname for it, as well as upload our site to the VM so we can start developing!

Configuring your Host OS

There’s one more step you need to perform in order for VDD to function properly on your system. You need to modify your machine’s hosts file so that you can visit your new VM by hostname instead of by typing in an IP Address.

Mac and Linux make this easy:

sudo vim /etc/hosts

Windows systems bury the file a little bit more:

notepad c:\windows\system32\drivers\etc\hosts

Then, paste in the following lines:

• 192.168.44.44 drupal8.dev
• 192.168.44.44 www.drupal8.dev
• 192.168.44.44 drupal7.dev
• 192.168.44.44 www.drupal7.dev

This instructs your workstation (the virtualization host) to assume that any domain name searches for http://drupal8.dev, http://www.drupal8.dev, http://drupal7.dev, and http://www.drupal7.dev, will route to 192.168.44.44 -- our VM’s IP address.

Pausing and Halting

If you look at the IP configuration above you’ll see that VDD, like most Vagrant managed VMs, assumes you’ll only run one at a time. This means you need to suspend or shutdown the VM to switch to another instance. This can be done from the directory containing the vagrantfile.

To suspend the VM (similar to Hibernating a PC):

cd my-vdd
vagrant pause

To shutdown the VM:

cd my-vdd
vagrant halt

To start the VM back up again, use vagrant resume if paused, or vagrant up if halted from the my-vdd/ directory.

Configuring the Guest’s Host File (Optional, unless using Simpletest)

If you plan on using the Simpletest framework on your VDD image, you will also need to configure the Guest’s /etc/hosts file. Without this, some Simpletest tests may fail, particularly if they are run from the command line. We can SSH into our vagrant image at any time by changing to our vdd directory, and using the vagrant ssh command:

cd my-vdd
vagrant ssh

This will drop you into an SSH session for the image. If you’re using Windows as a host OS, this is a bit more complicated. Once in the image, edit the /etc/hosts file as described above.

Note that from here you can use Linux system tools to reconfigure the VM, or use drush from the docroot of your site. This includes using drush si to install you site on the server and create the database.

Getting a Site onto VDD

Normally, you’d have to FTP your site’s files to and from the VM. Vagrant VMs, however, come configured with a shared directory that automatically syncs a directory on your host OS, to one on the guest OS. This eliminates the need to FTP files, and instead you can transfer them into the VM using Windows Explorer, the Finder, or whatever file manager you’re using on your host OS.

By default, the shared directory for VDD is the data/ directory of the directory two which you cloned the VDD repository:

The contents of the data/ directory correspond to the /home/vagrant/sites directory on the VDD VM. The drupal7 and drupal8 directories correspond to http://drupal7.dev, and http://drupal8.dev we configured earlier in our hosts file.

You can copy your site onto the VM now using file management tools, or you can wait until Part 4 when we use the IDE to do that for us.

Making Vagrant VMs Faster

While Vagrant and Virtualbox go a long way to be as fast as possible on your physical hardware, the performance can still be noticeably different between a VM and a installation on “bare metal”. There are a few simple things you can do to improve the VM’s performance.

Using NFS for Mac and Linux Hosts

By default, a vagrant VM uses a built-in file transfer mechanism to sync between the data/ directory and it’s counterpart inside the VM. While the transfer mechanism isn’t the fastest, it is supported on all of platforms that Vagrant supports.

A faster sync mechanism is to use the Network File System, or NFS. Macs come with NFS out of the box. Linux systems may also support NFS by installing the necessary drivers and utilities using your system’s native package manager (On Ubuntu, apt-get install nfs-kernel-server). Once you have NFS set up on your host OS, enabling it on the VM is easy.

For VDD images, open the config.json file in the directory in which your cloned the image (my-vdd). Locate the following lines:

"synced_folders": [
     {
       "host_path": "data/",
       "guest_path": "/var/www",
       "type": "default"
     }
   ],

And change the type field to nfs:

   "synced_folders": [
     {
       "host_path": "data/",
       "guest_path": "/var/www",
       "type": "nfs"
     }
   ],

Then restart the VM by executing the following command in the my-vdd directory:

vagrant reload

Note that it’s best to use the default sync option when initially upping the VM. Sometimes using NFS from the start can cause weird configuration issues and make the vagrant up command fail.

Using SSHFS on Windows Hosts

If you’re developing on a Windows-based workstation, you can use SSHFS instead. SSHFS uses the SFTP protocol to create a mounted drive on your host system. Consult the Getting Started with VDD page on Drupal.org for instructions (search for “sshfs”).

CPU and Memory Tweaking

If you want to squeeze even more performance out of the VM, you may want to modify the amount of CPUs to the VM. Memory is usually only a concern if you are actively exhausting the VM’s memory. Adding more memory does not result in more performance.

Open the Virtualbox application on the host OS, and locate the VM in the list. VDD images will start with vdd_default_. Select the VM, then click Settings. 

In the Settings window, click System. Then, select Processor.

VDD typically is allocated 1 CPU and 1GB of memory. This is more than enough for most Drupal sites. However, this means that the VM is using the same CPU to both run the OS and power the web stack. If your workstation is a quad core or greater system, allocating an additional CPU to the VM can greatly boost performance. Additional gains may be made when allocating greater than two CPUs to the VM, but with diminishing returns. Once you’ve reconfigured the VM, issue vagrant reload.

Summary

Now we have our site on our VM, and our VM performance tuned, we can now integrate it with our IDE. That’s what we’ll cover next time.