virtualbox

After doing a video testing different external GPUs on a Raspberry Pi last week, I realized two things:

1. Compiling the Linux kernel on a Raspberry Pi is slow. It took 54 minutes, and I ended up doing it 7 times during the course of testing for that video.
2. If you ever want to figure out a better way to do something, write a blog post or create a video showing the less optimal way of doing it.

To the second point, about every fifth comment was telling me to cross-compile Linux on a faster machine instead of doing it on the Pi itself. For example:

And on the Pi Forums, it seems like nobody worth their salt compiles the kernel on the Pi either, so I figured—since I'm probably going to have to do it again another thousand times in my life—I might as well put together a guide for how to do it on a Mac.

Since this is the third time I've burned more than a few hours on this particular problem, I thought I'd finally write up a blog post. Hopefully I find this post in the future, the fourth time I run into the problem.

What problem is that? Well, when I build a new Kubernetes cluster with multiple nodes in VirtualBox (usually orchestrated with Vagrant and Ansible, using my geerlingguy.kubernetes role), I get everything running. kubectl works fine, all pods (including CoreDNS, Flannel or Calico, kube-apiserver, the scheduler) report Running, and everything in the cluster seems right. But there are lots of strange networking issues.

Sometimes internal DNS queries work. Most of the time not. I can't ping other pods by their IP address. Some of the debugging I do includes:

VirtualBox's native shared folders will be used by default on Windows with the type of your synced folder set to nfs, or if it's not set. This method works great in many cases, but can be fairly slow when doing work with projects with many files in a synced folder, as is often the case with Drupal sites that I work with in Drupal VM.

Another option is to switch the type to smb. This is often a plug-and-play change (vagrant reload to make the change take effect—you'll likely need to enter in your Windows username and password during the startup process. However, symlinks inside the synced folder will likely break, and so we need to make one more important change:

The synced folder configuration needs to have:

[Update 2015-08-25: I reran some of the tests using two different settings in VirtualBox. First, I explicitly set KVM as the paravirtualization mode (it was saved as 'Legacy' by default, due to a bug in VirtualBox 5.0.0), which showed impressive performance improvements, making VirtualBox perform 1.5-2x faster, and bringing some benchmarks to a dead heat with VMware Fusion. I also set the virtual network card to use 'virtio' instead of emulating an Intel PRO/1000 MT card, but this made little difference in raw network throughput or any other benchmarks.]

My Mac spends the majority of the day running at between one and a dozen VMs. I do all my development (besides iOS or Mac dev) running code inside VMs, and for many years I used VirtualBox, a free virtualization tool, along with Vagrant and Ansible, to build and manage all these VMs.

Many blog posts have outlined the benefits of using VMs (Virtual Machines) for local Drupal development instead of either using native PHP and Apache, or a bundled environment like MAMP, XAMPP, or Acquia Dev Desktop. The advantages of using virtualization (usually managed by Vagrant) are numerous, but in certain cases, you can make a good argument for sticking with the traditional solutions.

If you'd like to take the dive and start using virtualized development environments, or if you're already using Vagrant and VirtualBox or some other VM environment (e.g. VMWare Fusion or Parallels Desktop), how do you optimize local development, and which pre-bundled Drupal development VM will be best for you and your team?

Criteria for the Perfect Local Development Environment

These are the criteria I use when judging solutions for local Drupal development (whether virtualized or traditional):

• Should be simple and easy to set up
• Should be fast by default
• Should be flexible:
  • Should work with multiple providers; VirtualBox is free, but VMWare can be much faster!
  • Should allow configuration of the PHP version.
  • Should work with your preferred development workflow (e.g. drush, makefiles, manual database sync, etc.)
  • Should prevent filesystem friction (e.g. permissions issues, slow file access speeds, etc.)
  • Shouldn't have hardcoded defaults
• Should be complete:
  • Should work without requiring a bunch of extra plugins or 3rd party tools
  • No extra languages or libraries should be required (why install Ruby gems, npm modules, etc. unless you need them for your particular project?)
• Should be Free and Open Source
• Should include all the tools you need, but allow you to disable whatever you don't need (e.g. XHProf, Apache Solr, etc.)
• Should work on Windows, Mac, and Linux with minimal or no adjustment
• Should be deployable to production (so your local dev environment matches prod exactly)

A lot of these points may have more or less importance to a particular team or individual developer. If you're a die-hard Mac user and don't ever work with any developers on Windows or Linux, you don't need to worry about Windows support. But some of these points apply to everyone, like being fast, simple, and flexible.

Since I'm running a Mac, and don't have a spare linux-running machine that can mount ext4-formatted partitions (like those used by default for official Raspberry Pi distributions like Raspbian on SD cards), I don't have a simple way to mount the boot partition on my Mac to tweak files on the Pi; this is a necessity if, for example, you break some critical configuration and the Pi no longer boots cleanly.

To mount an ext4-formatted SD or microSD card on a Mac, the easiest option is to use VirtualBox (and, in my case, Vagrant with one of Midwestern Mac's Ubuntu boxes). Boot a new linux VM (any kind will do, as long as it's modern enough to support ext4), shut it down, go into Settings for the VM inside VirtualBox and enable USB, then reboot.

Follow these steps once the VM is booted, to mount the flash drive:

It's been a well-known fact that using native VirtualBox or VMWare shared folders is a terrible idea if you're developing a Drupal site (or some other site that uses thousands of files in hundreds of folders). The most common recommendation is to switch to NFS for shared folders.

NFS shared folders are a decent solution, and using NFS does indeed speed up performance quite a bit (usually on the order of 20-50x for a file-heavy framework like Drupal!). However, it has it's downsides: it requires extra effort to get running on Windows, requires NFS support inside the VM (not all Vagrant base boxes provide support by default), and is not actually all that fast—in comparison to native filesystem performance.

I was developing a relatively large Drupal site lately, with over 200 modules enabled, meaning there were literally thousands of files and hundreds of directories that Drupal would end up scanning/including on every page request. For some reason, even simple pages like admin forms would take 2+ seconds to load, and digging into the situation with XHProf, I found a likely culprit:

In support of my mission to make local development easier and faster, I've released boxes for four of the most popular Linux distributions I use and see used for Drupal sites: CentOS 6/7 and Ubuntu 12.04/14.04.

Every now and then, a project I'm managing through Vagrant (using either a box I built myself using Packer, or one of the many freely available Vagrant Boxes) needs more than the 8-12 GB that's configured for the disk image by default. Often, you can find ways around increasing the disk image size (like proxying file storage, mounting a shared folder, etc.), but sometimes it's just easier to expand the disk image.

Unfortunately, VBoxManage's modifyvm --resize option doesn't work with .vmdk disk images (the default format used with Vagrant boxes in VirtualBox). Luckily, you can easily clone the image to a .vdi image (which can be resized), then either use that image, or convert it back to a .vmdk image. Either way, you can expand your virtual disk image however large you want (up to the available free space on your physical drive, of course!).

Here's how:

1 - Convert and resize the disk image

First, vagrant halt/shutdown your VM, then in Terminal or on the command line: