By day, TNS contributing writer Suchakra Sharma tinkers around with Linux kernel during his research at DORSAL (Distributed Open Reliable Systems Analysis Lab), which is part of the software engineering and computer engineering department of École Polytechnique de Montréal. We asked Sharma to explain how the lab uses Vagrant software to minimize the prep work for their tests and benchmarks.
I was introduced to Vagrant, software offered by Hashicorp for setting up development environments, earlier this year by a labmate, who gave me some sane advice for generating reproducible experiments in our research.
At its core, Vagrant is just a minimalist fancy wrapper for managing VMs. But the clear commands it offers to execute simple actions such as creating, destroying, provisioning and managing VMs can make all the difference to a researcher struggling to manage a VM-laden development environment.
Prior to encountering Vagrant, my brain’s default setting for automation has been to dive into script extravaganza, sometimes by generating C source files that run on template engines like Jinja. I firmly believe that any complex task for automation can be broken down to a certain number of Bash or Python scripts that call each other until the task is done, or fail because you screwed up somewhere.
Kernel development drove me to Vagrant. I needed to set up multiple copies of virtual machines that would run multiple tweaked kernels that would be created and discarded on a daily basis. Some days, I would just spend most of my time creating multiple VMs using VirtualBox or VMM, re-configuring them, managing snapshots etc and then trying my best to fit all of this with a scripting mindset.
For such tasks specifically, Vagrant proved to be a life-saver and fits just right in the workflow.
Vagrant helps keep the development environment as close to the production environment. It also provides an easy way for the development team to share a base configuration. The pre-configured development VMs can be moved from place to place, across networks and even shared and linked together.
With Vagrant, not only is it possible to have a portable work environment that “just works” now, but one that is truly collaborative one as well.
No more of those ugly clicks or learning separate commands and scripts for different providers like libvirt or VirtualBox. This is the one universal way now to manage VMs.
Tools like Vagrant and its upcoming successor Otto are indispensable for people in DevOps roles. However, what use does it have in a research environment?
Two inevitable parts of research life are rigorous testing/benchmarking and endless tinkering around with stuff that may seem insignificant to outsiders. When you do something like kernel development, you would end up in a cycle of making and breaking multiple VMs all the time.
Everyone has a different strategy for carrying out research and to get maximum output. Mine is to remain minimal, using a TUI (Textual User Interface) or CLI, and running lots of scripts for automation. Spending endless times in wizards to configure that tiniest network related checkbox so that your host-VM interface works on your LAN is not efficient. On the contrary, doing a simple
vagrant up opened a whole new world for me.
A Simple Vagrant Kernel Development Setup
First of all, Vagrant will need a provider that it supports, such as VirtualBox, VMware, AWS or libvirt. I am choosing libvirt for now as we use this in our lab.
$ sudo dnf install vagrant $ sudo dnf install libxslt-devel libxml2-devel libvirt-devel libguestfs-tools-c
Lets get that vagrant libvirt plugin now,
$ vagrant plugin install vagrant-libvirt
Next, we need a base box. For this, you can go through the Hashicorp Atlas or other websites such as vagrantbox.es. Many distributions or your friends can also provide the boxes that you can use and setup yourself using vagrant box add <your box name> command.
$ vagrant init fedora/23-cloud-base
This just places a Vagrantfile into your working directory which is now ready to roll and/or customize! Lets start by fine tuning the machine itself. Modify the Vagrantfile by erasing everything and adding contents of Vagrantfile from the following:
The bootstrap.sh file is used for provisioning the VM. Apart from the shell, there are other tools like Puppet, Chef etc. are supported as well.
$ vagrant up --provider libvirt
This command fetches the box image from the Hashicorp’s Atlas. It sets up the machine based on the provider and provisioning details if any and starts the VM. We are mostly set and the VM is up!
The best part about Vagrant is that you can just SSH to the machine by a simple
$ vagrant ssh
If you have multiple directories of development, just
vagrant up and
vagrant ssh in those directories to start individual VMs. You can also stop the machine by
vagrant halt or if you plan to permanently discard it, just do
So lets see now what more can be done and how it benefits in complex development scenarios.
I am trying out varying patches (P1, P2) on multiple kernel versions (V1, V2, V3, V4, V5) and I wanted to try them out in the same time. The patches are picked by me incrementally from a version controlled repository of my own module (M1). Upon patching and installing the kernels on the VMs, I want to run my tests (T1, T2 T3). Also, this is a daily routine.
No problem. Just use the same base box and fire up multiple VM instances and independently provision them with your desired kernel. Apply patches, build the kernels, reboot run tests again all at the same time. You can use multi-machine setup in Vagrant for your ease.
Also, a nice tip is to have your kernel module repo version controlled and sync that directory in the VM you are launching with the help of synced folders configuration in Vagrantfile. So what you may end up doing in your Vagrantfile to sync your module across VMs is something like this
This will sync my M1 module from the host to the /home/vagrant/M1 in the guest. You can keep all your Vagrantfile version controlled with different provisioning for different VMs.
I am stuck at a test T2 with a V4 kernel version patched with P2 on a VM instance. I want to make changes to my module, but I need expert help from the amazing folks in my lab. How can my co-worker make changes to my module and test it out on my VMs?
No problem. Vagrant has something called Vagrant Share that makes sharing VMs and collaborative work painless. The hassle of sharing VMs with all those settings just goes away with a simple command like,
$ vagrant share --ssh $ vagrant connect --ssh <machine-name>
Keep in mind that sharing requires account on Hashicorp Atlas. An alternative is to configure network yourself in the Vagrantfile.
Useful Setups for Research
- GaaS. Quite often, I have had to change machines for running my tests and I use a custom script for setting things up at first run. I also use R and RStudio or simple Gnuplot based on how complex the analysis can get. To save time in your research teams, you can setup a local “GaaS” as I call it, “Graphing as a Service.” It is essentially something like RStudio Server inside a VM configured with all your libraries. Vagrant multi-machine setup can be used for this as well. I have not tested this setup in our lab, but possibly centralizing and virtualizing graphing needs can be quite beneficial for research groups.
- Vagrant Package. With VirtualBox providers, it is also possible to just take the current Vagrant setup and make Vagrant Box out of it. Have a look at the Vagrant Package command. This can be beneficial when a new member arrives in the group and wants to warm up to some action quickly.
- Demos. It is probably statistically impossible to deliver a demo without screwing up somewhere or the other. But to improve the odds of a seamless demo in conference presentations or discussions with supervisor, keep a VM dedicated with your demos handy for sharing it physically or with
If you have an interesting way in which you use Vagrant, do share.