Categories

## Setting a different libvirt uri for Vagrant

HashiCorp Vagrant normally selects the right hypervisor, but the version shipped with Fedora 30 prefers to run within the QEMU user session of the hypervisor. A .Vagrantfile it would match the default behavior which doesn’t require any system privileges is shown below.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
config.vm.synced_folder ".", "/vagrant", disabled: true
config.vm.define "test01" do |test01|
config.vm.box = "centos/7"
config.vm.box_version = "1902.01"
config.vm.hostname = "test01.localdomain"
config.vm.provider :libvirt do |domain|
domain.uri = 'qemu:///session'
end
end
end


In some cases a virtual machine needs to run on QEMU system level and that can be done by changing the domain.uri from “qemu:///session” to “qemu:///system”. Vagrant now creates the virtual machine at the system level of the hypervisor and isn’t depending on any user environment to run.

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
config.vm.synced_folder ".", "/vagrant", disabled: true
config.vm.define "test01" do |test01|
config.vm.box = "centos/7"
config.vm.box_version = "1902.01"
config.vm.hostname = "test01.localdomain"
config.vm.provider :libvirt do |domain|
domain.uri = 'qemu:///system'
end
end
end


Membership of group libvirt maybe required or the right permissions with sudo for example. The first isn’t really advised except on local development system and then even sudo is still advised to reduce any accidental errors.

Categories

## Switching from VirtualBox to KVM (maybe)

I have been a VirtualBox user for a long time, but since I’m now looking more closely at BtrFS I also took a closer look at what is in \$HOME. VirtualBox harddisks and ISO-images are a large chunk of it and maybe the time has come to look at a different solution. One of the plans is to move virtual machines to a dedicated machine instead of running some on my workstation when I need them. This could give me more options for longer experiments as then my personal data doesn’t has to share the same encrypted volume with the virtual machines.

As VirtualBox is mainly a desktop solution, then the other options are Xen and KVM for now. I picked KVM as it is shipped with RHEL6 and part of the vanilla Linux kernel since 2007. Also there is a nice (remote) management solution and closer integration in GNOME 3.4 in the form of GNOME Boxes. So the time has come to give it a go and first we create a line in /etc/fstab to mount the BtrFS subvolume.

LABEL=datavol	/var/lib/libvirt	btrfs	defaults,relatime,nodiratime,subvol=libvirt	0	0


Now we create the BtrFS subvolume and mount it. Afterward we install all required software and make a user member of the right group. It is important to note that one needs to logout and login afterwards. These right are only needed when doing local maintenance.

sudo btrfs subvolume create libvirt /media/btrfs-datavol sudo mount /var/lib/libvirt
sudo apt-get install qemu-kvm virt-manager virt-viewer virtinst sudo usermod -a -G libvirt


The machine is now able to run virtual machines if it has an CPU with Intel-VT or AMD-V technology. And the first tests with Debian 6.0, Solaris 11 and Windows 7 looked very promising. The management interface is very clean and people who have worked with Solaris Container the commandline tool virsh is also a good option. One thing that seems to be missing is a storage snapshot option as in VirtualBox, but if it is a real miss I doubt as most images are on BtrFS and BtrFS supports snapshots on subvolume level.

For now KVM appears to be a good and free alternative for VirtualBox and VMWare. It may need some more love in the future, but for now it deserves some more testing from my side together with SELinux for stronger separation of virtual machines. Maybe I can say goodbye to DKMS for recompiling VirtualBox modules with every release and the Qt-toolkit as dependency for VirtualBox and switching back on the default GTK toolkit on my machine.