KVM, Ansible and how to deploy a test environment

In local development environments there is always a need for simulation of more powerful environments, as usually happens in the making of demos.

For this we’ll always follow the “KISS” philosophy (keep it simple stupid!) And we will use those services so that our Linux requires the least use of possible resources. We’ll need two tools to simplify the work that are Ansible for deployment and KVM as a hypervisor.

Images for the test environment

The first step is to raise a system that provides us with images in the simplest way possible. We’ll find that Vagrant as a wonderful source of images. We have two ways to use it:

  1. Download from https://www.vagrantup.com/downloads.html and install (with sudo dpkg -i vagrant_VERSION_x86_64.deb in Debian / Ubuntu environments or with sudo rpm -i vagrant_VERSION_x86_64.rpm in RHEL / Centos environments), to get an image as small as possible we will make use of a debian 9.9.0 with the following command:
    $ vagrant box add --provider libvirt debian/stretch64
    ==> box: Loading metadata for box 'debian/stretch64'
    box: URL: https://vagrantcloud.com/debian/stretch64
    ==> box: Adding box 'debian/stretch64' (v9.9.0) for provider: libvirt
    box: Downloading: https://vagrantcloud.com/debian/boxes/stretch64/versions/9.9.0/providers/libvirt.box
    box: Download redirected to host: vagrantcloud-files-production.s3.amazonaws.com
    ==> box: Successfully added box 'debian/stretch64' (v9.9.0) for 'libvirt'!
    The downloaded image will be in ~/.vagrant.d/boxes/debian-VAGRANTSLASH-stretch64/9.9.0/libvirt, in the form of three files, being the one that interests us: box.img which is an image with QCOW format.

  2. Directly download the images that we will use, for example a Centos image: http://cloud.centos.org/centos/7/vagrant/x86_64/images/CentOS-7.Libvirt.box and a Debian image: https://app.vagrantup.com/debian/boxes/stretch64/versions/9.9.0/providers/libvirt.box
    To make the deployment easier, Ansible has been configured to download automatically and save the image in /root/.images and use it directly without need to do anything else.

The next thing we need is to download the Ansible tasks that will allow us to launch our test environment, the “package” is formed by a file that will be really important called “inventory.yml” where we will really define how our demo will be, it is formed by a “creation” and a “destruction” file of the virtualized environment. The rest of the files are variables and functions (tasks) that will execute when is necessary to raise our environment. We proceed to download the environment with:

$ git clone https://github.com/aescanero/disasterproject
$ cd disasterproject/ansible

Inside the “ansible” directory we’ll found a “files” directory that has Vagrant’s insecure private key that will help us to access each of the machines that we will deploy. This key is obtained from https://raw.githubusercontent.com/hashicorp/vagrant/master/keys/vagrant, we proceed to change the permissions so that the key is accepted by SSH:

$ chmod 600 files/insecure_private_key

Download Ansible

In order to perform Ansible tasks, we must obtain and install Ansible following the instructions in the Ansible installation guide (https://docs.ansible.com/ansible/latest/installation_guide/intro_installation.html), for example for Debian you have to follow the next instructions:

$ sudo sh -c 'echo "deb http://ppa.launchpad.net/ansible/ansible/ubuntu trusty main" >>/etc/apt/sources.list'
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 93C4A3FD7BB9C367
$ sudo apt-get update && sudo apt-get install -y ansible 

Installing libvirt and KVM

Next is to install the rest of the packages that we will need, in debian they are:

$ sudo apt-get install -y libvirt-daemon-system python-libvirt python-lxml

In CentOs are:

$ sudo yum install -y libvirt-daemon-kvm python-lxml

To start the service we’ll execute $ sudo systemctl enable libvirtd && sudo systemctl start libvirtd

Create an inventory for the environment

In the next step we will edit the “inventory.yml” file that should have a format like that:

          memory: 1024
          vcpus: 1
          vm_ip: ""
          linux_flavor: "debian"
        domain: disasterproject.com
        network: "192.168.8"

We can see the definition of the machine/s (name: debian, memory in MB, number of vcpus, ip, and linux flavor – for now only debian or centos -) and a series of global values, as a domain , the network without the last octet (the network will be a class C, typical /24 mask, sufficient for demo enviroment), where {{network}}. 1 is the IP running as a gateway to all the virtual machines that we’ll deploy, the IPs of the virtual machines will be configured via DHCP and must belong to that network. Both {{network}}. 1 and the range {{network}}.240/28 are reserved and can’t be used for virtual machines.

Deploy the virtual machines

The next step is to launch the MVs with Ansible for this we execute:

$ ansible-playbook -i inventory.yml create.yml --ask-become-pass

We can see all the steps to deploy the virtual machine:

When the execution is finished correctly, the virtual machine/s are started and ready to use, in our example we can login to the MV with the IP with:

$ ssh -i files/insecure_private_key vagrant@

The vagrant user has sudo so we can manage the virtual machine without problems.

Comparing KVM and VirtualBox. Why KVM?

Finally, some conclusions over the performance of KVM and VIrtualBox hypervisors, although it is true that the VirtualBox console is efficient, the performance of this virtualization solution suffers when there is a lot of access to disk and / or CPU, although in the latest version (6. x) has clearly improved this, remains behind KVM and is not recommended for development or demos. More information on openbenchmarking: https://openbenchmarking.org/result/1812203-PTS-VIRTUALI66

Here are some results from iozone (/ usr / bin / iozone -s24m -r64 -i 0 -i 1 – + u -t 1) which indicate us improved performance in 3 of the 4 tests performed over a VM in KVM enviroment and VirtualBox enviroment:

Avg throughput per process Avg throughput per process
Throughput for 1 initial writers
922105.38 kB/sec
Throughput for 1 initial writers
712577.69 kB/sec
Throughput for 1 rewriters
1097535.38 kB/sec
Throughput for 1 rewriters
1244981.12 kB/sec
Throughput for 1 readers
2971712.50 kB/sec
Throughput for 1 readers
1833079.75 kB/sec
Throughput for 1 re-readers
2219869.75 kB/sec
Throughput for 1 re-readers
559970.25 kB/sec
Scroll to top