Traditional virtualization environments are those that predate what we know today as cloud environments—that is to say, they are straightforward hypervisors on which operating systems are run. Commercial examples such as VMware are common, as well as their open source counterparts such as Xen and KVM (and frameworks built off of these, such as oVirt).
As these technologies were originally built to supplement traditional physical environments, they present several possible options for building out your Enterprise Linux estate. For example, most of these platforms support the same network-booting capabilities as their bare-metal counterparts, and hence we could actually just pretend they are bare metal and continue with a network booting methodology.
However, virtualized environments introduced something that was difficult to achieve in physical environments because of the differences in hardware between the bare-metal devices on which they all ran—templates. A templated virtual machine is quite simply a deployable snapshot of a preconfigured virtual machine. Hence, you might build out the perfect CentOS 7 image for your enterprise, integrate your monitoring platform, perform all of the security hardening required, and then, using tools built into the virtualization platform itself, turn it into a template. The following is a screenshot of the CentOS 7 templates in the author's lab environment:
Each of these templates is a fully configured CentOS 7 base image ready to be deployed, with all pre-deployment work such as removal of SSH host keys completed. As a result, all an administrator has to do is to select the appropriate template and click on the New VM button—the process will be similar in platforms other than RHV, as most mainstream virtualization solutions provide this functionality in some guise.
This is in itself a fairly straightforward process, but it requires a little care and attention. For example, nearly all Linux servers these days have SSH turned on, and the SSH daemon on each server has a unique host identification key that is used to prevent (amongst other things) man-in-the-middle attacks. If you template a preconfigured operating system, you will also template these keys, which means a distinct possibility of duplicates across your environment. This reduces security quite considerably. It is hence very important to perform several steps to prepare your virtual machine before turning it into a template, and one such common step is to delete the SSH host keys.
Servers created using the PXE method do not suffer from this problem, as they are all installed from scratch and hence there are no historic log entries to clean up and no duplicate SSH keys.
In Chapter 5, Using Ansible to Build Virtual Machine Templates for Deployment, we will go into detail on creating virtual machine templates suitable for templating using Ansible. Although both the PXE boot and template deployment methodologies are equally valid for virtualized environments, most people find the templated route to be more efficient and easier to manage, and for this reason, I also advocate it (for example, most PXE boot environments need to know the MAC address of the network interface used on the physical or virtual server being deployed—this is not a necessary step in template deployment).