Looking at libvirt

A popular virtualization management software collection is the libvirt library. This assortment includes the following elements:

• An application programming interface (API) library that is incorporated into several open-source VMMs (hypervisors), such as KVM
• A daemon, libvirtd, that operates on the VM host system and executes any needed VM guest system management tasks, such as starting and stopping the VM
• Command-line utilities, such as virt-install and virsh, that operate on the VM host system and are used to control and manage VM guest systems

While typically most command-line utilities that start with vir or virt employ the libvirt library, you can double-check this via the ldd command. An example is shown in Listing 29.1 on a CentOS distribution that has hypervisor packages installed.

Listing 29.1: Checking for libvirt employment using the ldd command

$ which virsh
/usr/bin/virsh
$
$ ldd /usr/bin/virsh | grep libvirt
        libvirt-lxc.so.0 => /lib64/libvirt‐lxc.so.0 (0x00007f4a3a10c000)
        libvirt-qemu.so.0 => /lib64/libvirt‐qemu.so.0 (0x00007f4a39f08000)
        libvirt.so.0 => /lib64/libvirt.so.0 (0x00007f4a39934000)
$

A primary goal of the libvirt project is to provide a single way to manage virtual machines. It supports a number of hypervisors, such as KVM, QEMU, Xen, VMware ESX, and so on. You can find out more about the libvirt project at the libvirt.org website.

Viewing virsh

One handy tool that uses the libvirt library is the virsh shell. It is a basic shell you can employ to manage your system’s virtual machines.

If you have a VMM (hypervisor) product installed, you can employ the virsh shell to create, remove, start, stop, and manage your virtual machines. An example of entering and exiting the virsh shell is shown in Listing 29.2. Keep in mind that super user privileges are typically needed for shell commands involving virtual machines.

Listing 29.2: Exploring the virsh shell

$ virsh
Welcome to virsh, the virtualization interactive terminal.

Type:  ’help’ for help with commands
       ’quit’ to quit

virsh #
virsh # exit

$

You don’t have to enter into the virsh shell in order to manage your virtual machines. The various virsh commands can be entered directly from the Bash shell, which makes it useful for those who wish to employ the commands in shell scripts to automate virtual machine administration. An example of using the virsh utility interactively is shown in Listing 29.3.

Listing 29.3: Using the virsh utility interactively

$ virsh help setvcpus
  NAME
    setvcpus - change number of virtual CPUs

  SYNOPSIS
    setvcpus <domain> <count> [&hyphen;&hyphen;maximum] [&hyphen;&hyphen;config]
[--live] [--current] [--guest] [--hotpluggable]

  DESCRIPTION
    Change the number of virtual CPUs in the guest domain.

  OPTIONS
    [--domain] <string>  domain name, id or uuid
    [--count] <number>  number of virtual CPUs
    --maximum        set maximum limit on next boot
    --config         affect next boot
    --live           affect running domain
    --current        affect current domain
    --guest          modify cpu state in the guest
    --hotpluggable   make added vcpus hot(un)pluggable


$

Managing with Virtual Machine Manager

Not to be confused with a hypervisor (VMM), the Virtual Machine Manager (also called vmm) is a lightweight desktop application for creating and managing virtual machines. It is a Python program available on many distributions that employ a GUI and is obtainable from the virt-manager package.

The Virtual Machine Manager can be initiated from a terminal emulator within the graphical environment via the virt-manager command. The Virtual Machine Manager user interface is shown on a CentOS 7 distribution in Figure 29.1.

You do need to use super user privileges to run the Virtual Machine Manager, and if the virt-manager command is not issued from an account with those privileges, it will provide a pop-up window asking for the root account password or something similar, depending on the distribution.

One nice feature the Virtual Machine Manager provides through its View menu is performance statistic graphs. In addition, the GUI interface allows modification of guest virtual machines’ configurations, such as their virtual networks (virtual network configurations are covered later in this chapter).

You can view screen shots of the Virtual Machine Manager, read its documentation, and peruse its code at the virt-manager.org website.

Booting with Shell Scripts

Whether you are creating guest virtual machines in the cloud or on your own local host machine, there are various ways to get them booted. Starting a few VMs via a GUI is not too terribly difficult, but if your company employs hundreds of virtual machines, you need to consider automating the process.

Using shell scripts for booting virtual machines is typically a build-your-own approach, though there are many examples on the Internet. It works best for booting guest virtual machines on a company-controlled host machine.

You can create configuration files for your various virtual machines and read them into the shell script(s) for booting as needed. The guest can be booted, when the host system starts, at predetermined times, or on demand. This is a flexible approach that allows a great deal of customization.

Kick-Starting with Anaconda

You can quickly and rather easily bootstrap a new system (physical or virtual) using the kickstart installation method. This RHEL-based technique for setting up and conducting a system installation consists of the following:

1. Create a kickstart file to configure the system.
2. Store the kickstart file on the network or on a detachable device, such as a USB flash drive.
3. Place the installation source (e.g., ISO file) where it is accessible to the kickstart process.
4. Create a boot medium that will initiate the kickstart process.
5. Kick off the kickstart installation.

# cat /root/anaconda-ks.cfg
#version=DEVEL
# System authorization information
auth --enableshadow --passalgo=sha512
# Use CDROM installation media
cdrom
# Use graphical install
graphical
# Run the Setup Agent on first boot
firstboot --enable
# Keyboard layouts
keyboard --vckeymap=us --xlayouts=’us’
# System language
lang en_US.UTF-8

# Network information
network  --bootproto=dhcp --device=enp0s3 […]
network  --bootproto=dhcp --device=enp0s8 […]
network  --hostname=localhost.localdomain

# Root password
rootpw --iscrypted $6$BeVyWOTQ9PdmzOO3$ri2[…]
# System services
services --enabled="chronyd"
# System timezone
timezone America/New_York --isUtc
user --name=Christine --password=$6$LzENYr[…]
# System bootloader configuration
bootloader --append=" crashkernel=auto" --[…]

# Partition clearing information
clearpart --none --initlabel

%packages
@^minimal
@core
chrony
kexec-tools

%end

%addon com_redhat_kdump --enable --reserve-mb=’auto’

%end

%anaconda
[…]
%end
#

# ls VM-Install/
ks.cfg  ubuntu-18.04.1-live-server-amd64.iso
#

--initrd-inject /root/VM-Install/ks.cfg
--extra-args="ks=file:/ks.cfg console=tty0 console=ttyS0,115200n8"

Initializing with Cloud-init

Cloud-init is a Canonical product (the same people who produce the Ubuntu distributions). It provides a way to bootstrap virtualized machines. Canonical on its cloud-init website, cloud-init.io, describes it best, “Cloud images are operating system templates and every instance starts out as an identical clone of every other instance. It is the user data that gives every cloud instance its personality and cloud-init is the tool that applies user data to your instances automatically.”

The cloud-init service is written in Python and is available for cloud-based virtualization services, such as Amazon Web Services (AWS), Microsoft Azure, and Digital Ocean as well as with cloud-based management operating systems, like OpenStack. And your virtual machines don’t have to be in a cloud to use cloud-init. It can also bootstrap local virtual machines using VMM (hypervisor) products like VMware and KVM. In addition, it is supported by most major Linux distributions. It is called an industry standard for a reason.

Cloud-init allows you to configure the virtual machine’s hostname, temporary mount points, and the default locale. Even better, pre-generated OpenSSH private keys can be created to provide encrypted access to the virtualized system. Customized scripts can be employed to run when the virtual machine is bootstrapped. This is all done through what is called user-data, which is either a string of information or data stored in files that are typically Yet Another Markup Language (YAML) formatted files.

The /etc/cloud/cloud.cfg file is the primary cloud-init configuration file. The command-line utility name is, as you might suspect, the cloud-init command. An example of using cloud-init to get help is shown in Listing 29.6.

Listing 29.6: Employing the -h option to get help on the cloud-init command

$ cloud-init -h
usage: /usr/bin/cloud-init [-h] [--version] [--file FILES] [--debug] [--force]
 {init,modules,single,query,dhclient-hook,features,analyze,devel,
collect-logs,clean,status}
                           ...

optional arguments:
  -h, --help            show this help message and exit
  --version, -v         show program’s version number and exit
  --file FILES, -f FILES
                        additional yaml configuration files to use
  --debug, -d           show additional pre-action logging (default: False)
  --force               force running even if no datasource is found (use at
                        your own risk)

Subcommands:
  {init,modules,single,query,dhclient-hook,features,analyze,devel,
collect-logs,clean,status}
    init                initializes cloud-init and performs initial modules
    modules             activates modules using a given configuration key
    single              run a single module
    query               Query standardized instance metadata from the command
                        line.
    dhclient-hook       run the dhclient hookto record network info
    features            list defined features
    analyze             Devel tool: Analyze cloud-init logs and data
    devel               Run development tools
    collect-logs        Collect and tar all cloud-init debug info
    clean               Remove logs and artifacts so cloud-init can re-run.
    status              Report cloud-init status or wait on completion.
$

Virtualizing the Network

Network virtualization has been evolving over the last few years. While it used to simply mean the virtualization of switches and routers running at OSI level 2 and 3, it can now incorporate firewalls, server load balancing, and more at higher OSI levels. Some cloud providers are even offering Network as a Service (NaaS).

Two basic network virtualization concepts are virtualized local area networks (VLANs) and overlay networks.

VLAN To understand a VLAN, it is best to start with a local area network (LAN) description. Systems and various devices on a LAN are typically located in a small area, such as an office or building. They share a common communications line or wireless link, are often broken up into different network segments, and their network traffic travels at relatively high speeds.

A VLAN consists of systems and various devices on a LAN, too. However, this group of systems and various devices can be physically located across various LAN subnets. Instead of physical locations and connections, VLANs are based on logical and virtualized connections and use layer 2 to broadcast messages. Routers, which operate at layer 3, are used to implement this LAN virtualization.

Overlay Network An overlay network is a network virtualization method that uses encapsulation and communication channel bandwidth tunneling. A network’s communication medium (wired or wireless) is virtually split into different channels. Each channel is assigned to a particular service or device. Packets traveling over the channels are first encapsulated inside another packet for the trip. When the receiving end of the tunneled channel gets the encapsulated packet, the packet is removed from its capsule and handled.

With an overlay network, applications manage the network infrastructure. Besides the typical network hardware, this network type employs virtual switches, tunneling protocols, and software-defined networking (SDN). Software-defined networking is a method for controlling and managing network communications via software. It consists of an SDN controller program as well as two application programming interfaces called northbound and southbound. Other applications on the network see the SDN as a logical network switch.

Overlay networks offer better flexibility and utilization than non-virtualized network solutions. They also reduce costs and provide significant scalability.

Configuring Virtualized NICs

Virtual NICs (adapters) are sometimes directly connected to the host system’s physical NIC. Other times they are connected to a virtualized switch, depending on the configuration and the employed hypervisor. An example of a VM’s adapter using a virtual switch is shown in Figure 29.2.

When configuring a virtual machine’s NIC, you have lots of choices. It is critical to understand your options in order to make the correct selections.

Host-Only A host-only adapter (sometimes called a local adapter) connects to a virtual network contained within the virtual machine’s host system. There is no connection to the external physical (or virtual) network to which the host system is attached.

The result is speed. If the host system has two or more virtual machines, the network speed between the VMs is rather fast. This is because VMs’ network traffic does not travel along wires or through the air but instead takes place in the host system’s RAM.

This configuration also provides enhanced security. A virtual proxy server is a good example. Typically, a proxy server is located between a local system and the Internet. Any web requests sent to the Internet by the local system are intercepted by the proxy server that then forwards them. It can cache data to enhance performance, act as a firewall, and provide privacy and security. One virtual machine on the host can act as a proxy server utilizing a different NIC configuration and have the ability to access the external network. The other virtual machine employing the host-only adapter sends/receives its web requests through the VM proxy server, increasing its protection.

Bridged A bridged NIC makes the virtual machine like a node on the LAN or VLAN to which the host system is attached. The VM gets its own IP address and can be seen on the network.

In this configuration, the virtual NIC is connected to a host machine’s physical NIC. It transmits its own traffic to/from the external physical (or virtual) network.

This configuration is employed in the earlier virtual proxy server example. The proxy server’s NIC is configured as a bridged host, so it can reach the external network and operate as a regular system node on the network.

NAT A network address translation (NAT) adapter configuration operates in a way that’s similar to how NAT operates in the physical world. NAT in the physical networking realm uses a network device, such as a router, to “hide” a LAN computer system’s IP address when that computer sends traffic out onto another network segment. All the other LAN systems’ IP addresses are translated into a single IP address to other network segments. The router tracks each LAN computer’s external traffic, so when traffic is sent back to that system, it is routed to the appropriate computer.

With virtualization, the NAT table is maintained by the hypervisor instead of a network device. Also, the IP address of the host system is employed as the single IP address that is sent out onto the external network. Each virtual machine has its own IP address within the host system’s virtual network.

Physical and virtual system NAT has the same benefits. One of those is enhanced security by keeping internal IP addresses private from the external network.

Dual-Homed In the physical world, a dual-homed system (sometimes called a multi-homed system) is a computer that has one or more active network adapters. Often a physical host is configured with multiple NICs. This configuration provides redundancy. If one physical NIC goes bad, the load is handled by the others. In addition, it provides load balancing of external network traffic.

In the virtual world, many virtual machines are dual-homed or even multi-homed, depending on the virtual networking environment configuration and goals. Looking back to our virtual proxy server example, it is dual-homed, with one internal network NIC (host-only) to communicate with the protected virtual machine, and it has a bridged adapter to transmit and receive packets on the external network. Figure 29.3 shows the complete network picture of this virtual proxy server.

The physical and virtual machine network adapter configuration has performance and security implications. Understanding your internal virtual and external physical networks and goals is an important part of making these choices.