{"id":24099,"date":"2015-05-13T08:48:33","date_gmt":"2015-05-13T06:48:33","guid":{"rendered":"https:\/\/mamchenkov.net\/wordpress\/?p=24099"},"modified":"2015-05-13T08:52:52","modified_gmt":"2015-05-13T06:52:52","slug":"vagrant-libvirt-fedora-21","status":"publish","type":"post","link":"https:\/\/mamchenkov.net\/wordpress\/2015\/05\/13\/vagrant-libvirt-fedora-21\/","title":{"rendered":"Vagrant adventures on Fedora 21"},"content":{"rendered":"\n

I spent a large chunk of yesterday experimenting with Vagrant<\/a> on my Fedora 21<\/a> laptop. \u00a0I’ve used it before of course, but a friend asked for help with something I was planning to play with for a long time, so it\u00a0unexpectedly lead me into a journey.<\/p>\n

Let’s start simple. \u00a0If you want the least possible amount of hassle with running Vagrant on Fedora, you should use it with Oracle VirtualBox<\/a> provider (sometimes also called hypervisor). \u00a0 It works great! \u00a0The only troubles with this approach is that VirtualBox relies on a kernel module (kmod-VirtualBox RPM), which has to match your current running kernel version to a digit. \u00a0This kernel module is NOT part of the official Fedora repositories, and, instead, can be found in the RPM Fusion<\/a> yum repository (rpmfusion-free-updates). \u00a0This means that sometimes, when Fedora releases a kernel update, it might take a few days for the RPM Fusion repository to catch up with the kmod-VirtualBox updates. \u00a0And this, of course, might result in your Vagrant setup being broken.<\/p>\n

The easiest way to protect against that is to disable automatic kernel, kernel module and VirtualBox updates. \u00a0To do so, add the following line to the [main]<\/em> section of your \/etc\/yum.conf<\/em> file, right after your VirtualBox\/vagrant setup started to work:<\/p>\n

exclude=kernel* kmod-* VirtualBox*<\/pre>\n
Now, if you forgot to do that a few times got pissed off with this situation (or don’t like Oracle for some reason), you might consider alternatives. \u00a0Which are a few. \u00a0Vagrant supports a variety of hypervisors. \u00a0 One of the common alternatives is to use libvirt<\/a>, which is shipped with Fedora distribution.<\/p>\n
Installing libvirt is simple (thanks to this blog post<\/a>). \u00a0Here’s pretty much all you have to do:<\/p>\n
\r\nyum install libvirt libvirt-daemon libvirt-daemon-qemu virt-manager\r\nservice libvirtd restart\r\n<\/pre>\n
The problem that you might realize now is that libvirt is not the most popular provider for boxes in the Vagrant world. \u00a0Most people seem to prefer VirtualBox. \u00a0But if your choices are satisfied, I’m glad for you. \u00a0If they are not, however, there is a work around that you might go for – vagrant mutate plugin<\/a>. \u00a0This plugin converts vagrant boxes from one hypervisor to another.<\/p>\n
In order to install this plugin on Fedora 21 you’ll need a few development tools first (this StackOverflow thread<\/a> definitely helped with the weird g++ error):<\/p>\n
yum install ruby-devel gcc-c++ make<\/pre>\n
Once you have those, install the vagrant plugin with your regular user (the one who will run vagrant VMs):<\/p>\n
vagrant plugin install vagrant-mutate<\/pre>\n
Now you can mutate Vagrant boxes. \u00a0Unfortunately, you might find that mutate plugin doesn’t like boxes with\u00a0slash<\/a> in their names (like chef\/centos-6.5<\/a>). \u00a0The suggested workaround is to either use box names without slashes, or to provide mutate plugin with the box URLs, rather than names. \u00a0The official boxes directory<\/a> doesn’t give you URLs though, so you might be stack with random GitHub repositories or with an alternative directory, like Vagrantbox.es<\/a>.<\/p>\n
My adventures with this aren’t over yet. \u00a0 Feel free to send suggestions my way. \u00a0From my side, here are a couple of other useful links on this subject:<\/p>\n