Think of it like, “OpenStack for cheapskates.”

There are plenty of ways to automate the provisioning of virtual machines, and while this isn’t the best way it certainly works great for me. I am fortunate enough to have a very heterogeneous environment at home; aside from a few appliances nearly all my virtual machines are running Ubuntu 18.04. This approach certainly won’t work for those who have a mixed environment with different versions Linux, Windows, and BSD derivatives.

I’ve packaged this up as an Ansible role, go see it on GitHub!

System Components

For this to work, you essentially need these pieces:

• A dedicated computer to run KVM, with Linux already installed
• A network switch configured with tagged VLANs for the virtual networks on KVM
• A router or multilayer switch to handle the routing and network access for the VLANs
• A desktop/laptop computer with Ansible and Virt-Manager (optional) for managing the servers

I built this system for managing my own servers, so it’s entirely possible that there were oversights or assumptions.

VM Images

As I said earlier, I use Ubuntu 18.04 for my servers. This is the #1 assumption I’ve made by hardcoding this. However, this is where the real beauty of this system comes in.

Instead of using a system like Hashicorp Packer to build images, I simply download the exact same images used by OpenStack private cloud, as well as Docker and LXC containers. They’re a very minimal GNU/Linux install, but they’re more than enough for spinning up basic VMs.

When making new virtual machines, the scripts will first check if the server has an image saved, and download one if needed. Then, it will convert the image to .qcow format and clone it to make the new VM. Then the customization begins. Depending on the user-defined data, it will also expand the disk image.

Cloud-Config

The next nifty technology this integrates is the cloud-init system. Usually this is used to upload scripts to ec2 (Or other cloud providers) instances at launch time to automate the configuration. I use it for a similar purpose:

• Set the hostname and domain
• Configure users
• Add authorized SSH keys
• Either set DHCP or static IP

The script will generate cloud-config and network metadata files, then create an ISO image to attach to the VM. This is required since there is not metadata API in my ‘private cloud’, instead we must use local files that are read at boot.

Launch

To fire up the VM, we use the virt-install script with a set of default parameters. Initially, I used the libvirt_xml module in Ansible, but found it to be less flexible than just running a command in the playbook.

Examples

The following are examples of user-defined config that would live in the inventories/group_vars directory.

Users

This is a list of users that should be added to the server during provisioning.

The passwd and pub_key parameters take your hashed password and your SSH public key so that you are able to access the server after provisioning.

users: 
- name: ongo
  full_name: Ongo Gablogian 
  passwd: $6$rounds=2048$aaaaaaaa
  pub_key: ssh-rsa AAAAB3N [email protected]

VMs

This is a list of virtual machines that will be built. The only required parameters are the name, all others will fall back to default settings.

virtual_machines: 
- name: u18-svr-001
  cpu: 1
  mem: 1024
  disk: 10G
  bridge: br10 

A VM can also be created with a static IP address defined:

- name: u18-svr-002
  cpu: 1
  mem: 512 
  disk: 5G
  bridge: br10 
  net: 
    ip: 10.11.12.13/24
    gateway: 10.11.12.1 
    domain: gablogianartcollection.org
    dns: 
      - 1.1.1.1
      - 9.9.9.9

Default Settings

If these settings are not defined, the defaults will be applied when creating the virtual machine:

If no value is supplied, the default settings will be used:

Adding the role to your Ansible project

The best way to add this role is by using a Git submodule:

git submodule add https://github.com/noahbailey/ansible-qemu-kvm.git roles/kvm

Then, the role can be added to your main.yml or other top-level playbook:

---
- name: Provision Virtual Machines
  hosts: hypervisors
  become: true 
  roles: 
    - kvm

I keep this towards the top so that the VMs I provision will be configured later on in the same run.

Hopefully this was a good introduction to working with and automating Linux virtualization. Since I’ve moved away from ESXi I’ve really taken to liking KVM/QEMU for its simplicity and ease of automation.

As always, thanks for reading!