Automating KVM Virtualization
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!
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.
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.
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.
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.
The following are examples of user-defined config that would live in the
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 firstname.lastname@example.org
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: - 126.96.36.199 - 188.8.131.52
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:
|Bridge||Default libvirt NAT network|
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!