Kernel Virtual Machine (KVM)
KVM is a way to run several instances of operating systems on a single machine. Processes run on the KVM host that simulate a physical machine with CPUs, memory, disk space, network connectivity, and a console. Our machine Algernon has been designed specifically to host up to twenty instances of Linux, or less depending on how large we make our virtual machines. The Emerald workstation can host an additional five VMs or so.
Introduction
This document will describe how we install, maintain, and use our virtual machines using KVM and Ansible. In this document, a KVM host is a physical machine that runs the KVM software to simulate virtual machines, which are called KVM Guests. A KVM guest will be treated by Ansible and PXE like any other Linux machine.
Virtual machine host
We will host our virtual machines on one or more of the workstations, while keeping our options open to create dedicated KVM servers. The machine specifically designed to host VMs is Algernon, with a large memory and striped disks for speed.
These are the variables that govern the installation of a KVM host. They are defined in the host variables for the KVM server. By default we do not stripe the volume (value is 1).
| Variable | Contents | Default | Comments |
|---|---|---|---|
local_kvm_stripes |
Number of stripes for the /local/kvm volume | 1 | Set to 2 at Algernon |
Virtual machine host storage
We have one 500GB volume mounted under /local/kvm. Where possible, we will stripe these volumes for maximum performance. In this file system, we have the following directories:
- storage - This is where the QCOW2 files for the virtual machine's disks are stored.
- images - This is where we store QCOW2 files that we mean to copy to storage and assign to a virtual machine.
- xml - Configuration files, mostly in XML format, though certain files can be in JSON or YAML format.
Virtual hardware
In previous installations, our virtual machines ran in legacy mode. We will change this to UEFI in the NSCHOOL environment, so we can use our NSCHOOL boot/install servers to install the operating system on them. We will support a variable amount of memory, and a variable number of virtual CPUs, to be specified in the virtual machine's host files with defaults set in the KVM roles.
Configuration
For each class of machine, we have a specific XML definition file with the following features:
| Feature | Description | Variable | Default |
|---|---|---|---|
| name | Name of the virtual machine in KVM | inventory_hostname_short | None |
| currentMemory | Current amount of memory | class.memory_mb | 4096 MB |
| memory | Maximum amount of dynamically assignable memory | class.memory_mb | 4096 MB |
| vcpu | Number of virtual CPUs | class.nr_cpus | 2 |
| disk source(1) | Rootvg disk location | inventory_hostname_short | N/A |
(1) In the host's XML definition file, we assign it one rootvg disk in the basic configuration. If ever we need more than one rootvg disk, we create another class of virtual machine host. We store the qcow2 file in /local/kvm/storage/hostname-rootvg-00.
Machine classes
We will try to keep the number of virtual hardware configurations to a minimum. We will use XML file templates to define our virtual machines, with variables used for memory, and number of CPUs. We will use the following variables in every machine class:
| Variable | Contents | Default | Comments |
|---|---|---|---|
| class.class | Name for the VM's hardware configuration | basic | Repeated here so we can pass the entire variable to a role |
| class.memory_mb | Amount of RAM in megabytes | 4096 | Minimum amount needed for Linux |
| class.nr_cpus | Number of virtual CPUs | 2 | Deliberately kept small |
| class.rootvg_gb | Amount of rootvg storage in GB | 70 | Will mostly be left at default |
| class.home_network | Which network the guest is connected to | frontnet | Name to be determined at site definition time |
The basic standard VM with variables left at default is able to run on any of our KVM hosts. If we need more than the basic amount of RAM or CPU, we can define the variables in the host's host_var file. To start with, we will have the following classes:
- basic - A deliberately small and simple VM with one rootvg disk and a serial console
- openshift - A VM optimised for running OpenShift workloads using CoreOS
Basic machine
The basic VM has the following features:
- A UEFI virtual architecture with safe boot turned off
- Two virtual CPUs and 4GB in RAM
- One rootvg disk of the size specified above
- One Ethernet interface connected to its home network
- A graphical console
Openshift machine
Openshift VMs are designed for Fedora CoreOS running OpenShift workloads. They will usually have more CPU and RAM than the basic model and be connected to a private Openshift network. They may also use different methods of installation such as copying a standard rootvg disk.
Virtual machine storage
Storage for the KVM guests can be configured in many ways, but we will be using files stored on the KVM host, in a directory structure under /local/kvm/. We will be using the qcow2 format where one file on the KVM host represents a disk on the guest. We have three classes of storage: rootvg, datavg, and clustervg.
- The rootvg class is dedicated to the machine's operating system and any applications we run on the mahchine. By default, this will be one 70GB virtual disk.
- The datavg class is meant to store application data, and will normally survive a reinstallation of the system. How much if any datavg storage a machine has depends on the applications on the guest.
- The clustervg class is meant for storage items that are shared between multiple virtual machines, and used using technology like GPFS or Pacemaker. The virtual machines as such do not own this storage. It belongs to a cluster or shared-storage application.
We will reserve a space on every KVM host for iso images of installation media or CDs/DVDs of any kind. These can then be assigned to virtual machines.
Virtual machine network
There are two kinds of network connectivity for virtual machines: a direct virtual connection to the KVM host's Ethernet adapter, and a separate virtual network that may or may not be bridged to the outside. We will define these networks in Ansible variables.
Each virtual machine will have at least one virtual Ethernet inteface, connected to its home network. We may define extra network interfaces to create multi-homed virtual machines - for example OpenShift load balancers.
To avoid problems with dynamic networking, KVM hosts will not use DHCP, but assign their IP address and name server statically. All KVM guests will use DHCP, and will need to have their MAC addresses defined in Ansible.
Console access
KVM offers two kinds of system console: Serial or graphical. We will default to serial consoles for virtual machines, because those support cut and paste of text. We may define some machines to have graphical consoles.