Local Virtualization

The concept of virtualization involves a copy of an operating system running on virtual hardware that makes the operating system think it’s installed on physical hardware. Early virtualization usage basically meant hosting multiple virtual machines on a single host machine and using them as if they were just more servers that could be provisioned and used for services. This typically meant using VMware Workstation or Server, though many organizations used XEN or KVM—particularly those that were virtualizing only Linux systems. Most Windows virtualization occurred either on the aforementioned VMware products or on Windows virtualization offerings, such as Hyper-V and its predecessors.

Other People’s Linux Boxes

Eventually people began using virtualization that was concentrated at a given company and its datacenters, but not the local company or datacenter, such as the many organizations that rent physical or virtual servers (for example, HostGator, Linode, Rackspace). While this is a clear use of virtualization, it’s definitely not virtualization in the format we know today as the cloud virtualization.

Cloud Virtualization

The word cloud can mean a lot of things. Primarily, the terms cloud and cloud virtualization are used in connection with the three big cloud vendors: Amazon Web Services, Google Cloud, and Microsoft Azure. (Docker and Kubernetes are also mainstays in these large provider environments, but they are mainly out of scope of the Linux+ exam.)

The key point about cloud virtualization is that while it’s similar in some ways to other types of virtualization, it provides the capability to scale out provisioned resources to infinity. This is intelligent scaling that you can tune to favor cost savings, performance, or a mix of the two.

Amazon Machine Images

Amazon is the biggest vendor in the cloud space, and it’s good to recognize that the Amazon Machine Image (AMI) format is a force to be reckoned with in bootstrapping or cloud initialization. Think of an AMI as a template that includes a system root, an operating system, and whatever else you want to have included in the AMI.

An AMI is a bit like a frozen dinner: You can “thaw” one out and have it piping hot and ready in just a few seconds, but it’s prepackaged, and if you don’t like or want it customized, you have to rework it and then package it up all over again.

However, to say that an AMI is unalterable or that you can’t run scripts on it after it’s instantiated is inaccurate. Unless you change the AMI that’s being used to boot up an instance, you’ll always have to do the after-boot modifications, and if you’re doing that, why not just use one of the many awesome tools (for example, Chef, Puppet, Salt) for customization of the image?

Cloud Installation Tools

While the Linux+ exam objectives mention only Cloud-init, Anaconda, and Kickstart, you can also use tools such as Chef, Puppet, Salt, and SUSE Manager.

Cloud-init

Cloud-init is a unique tool. You can use it by itself, and it will allow you to do a lot with the customization of your cloud VM installs. However, its real strength lies in being the initial bootstrap tool that prepares the VM environment for the more feature-rich tools, such as Chef and Puppet.

Puppet

Named for the old science fiction movie The Puppet Masters, Puppet is an older technology that is still in wide use. Its key strength is in getting systems ready for serving what they are designed to serve. Its downside is that it’s a centralized system, and the failure of the central management node can be catastrophic. Puppet is also prone to bottlenecks due to its architecture.

Puppet has its own domain-specific language, and if you have learned it, Puppet is fairly easy to use. The Puppet language is a nonstandard implementation of the Ruby language with a lot of changes.

Chef

The designers of Puppet have learned a lot of lessons that have enabled them to make Chef a more viable, scalable, and healable infrastructure tool than Puppet. Designed from the get-go as a distributed tool that can use a central repository of objects, Chef doesn’t depend on that repo being constantly available to do its job.

Chef’s domain language is standards compliant with the Ruby language, so when a DevOps engineer gets to a point where the built-in implementation can’t handle a configuration issue, he or she can use the full Ruby language to solve the issue.

Chef is also designed to be massively scalable; it can handle upward of 250,000 nodes, which is another improvement on the Puppet tool.

Anaconda/Kickstart

Popularized in earlier versions of Red Hat Linux, the Kickstart installation method is used to automate unattended installations of Linux.

Kickstart uses a single file that contains all the configuration and automated responses necessary to perform a hands-off installation of a Linux (in most cases, Red Hat Enterprise Linux) system.

Kickstart requires the following components:

• Installation media (either locally or on a network resource)

• Kickstart file (the default is anaconda-ks.cfg)

• Boot method

Kickstart files are relatively simple, containing keywords for the items being queried or configured and values for the selections, settings, or answers to any installation questions.

A Kickstart file is broken up into several main sections:

• Command: This section contains the commands to install the distribution, including answers, if required

• Packages: This section lists the package selections to be installed, in a stanza that begins with %packages and ends with %end. The packages to be installed can be in groups, or they can appear as individual packages. Groups are prefaced with an @, such as @Sound and Video, whereas an individual package would just be referenced by the short package name, such as vim.

• Pre and post: These sections contain commands and functions to perform before installation and after installation. These sections are stanza based, beginning with %pre and ending with %end. It’s important to make sure that the Pre and Post sections are at the end of an Anaconda or Kickstart file.

VM Templates

A template is usually not a bootable or usable VM but a master version of a VM that is used to make a copy that can be customized into a VM for use in a particular environment.

An administrator might create a VM template, test and get it just right, and then, for a new software project, make a copy of the VM for each developer’s coding environment. The fact that the VM is identical is key here, so that everyone is working from the same software and settings.

OVA/OVF Templates

The use of OVA/OVF files as a template mechanism is different from using a simple VM template. An Open Virtual Appliance (OVA) file is effectively a bundling of one or more VMs together in an installable/runnable package such as a virtual appliance that might include a VM for NGINX and another for MySQL, packaged together and usable very quickly in an environment such as VMware. An Open Virtualization Format (OVF) file is a compressed package that contains any needed certificates and disk image files and that is similar in format to a TAR archive file. An OVA file can contain multiple OVF files, and each OVF file effectively represents a VM instance.

Configuring Templates

A lot of talk has been generated about whether it is best to use JSON or YAML for configuration management. The choice you make depends mostly on what you are doing.

YAML Ain’t Markup Language

YAML is a superset of (or encompasses) JSON. YAML is mainly used for configuration files with a stanza-based format of hierarchical items and is imminently human friendly and readable.

YAML also allows for a larger feature set, as well as the ability to include comments for documentation and clarity.

JSON Bourne

JSON is used as a way to serialize data. It’s simpler in format than YAML and can be used to conduct data exchange and transfer between APIs and their requesting applications or services.

JSON is a subset of YAML, and it can be parsed with a YAML interpreter or parser, so you can use YAML and JSON together for your templating needs.

Container Images

A container image is a binary file that has within it all the necessary components to run as a Docker container instance. Container images, like VM templates, make deploying many multiple instances of a given configuration a lot simpler.

A registry is, at its simplest, a collection of Docker container images that is named and tagged appropriately so that those wishing to pull and use a Docker image can do so easily. The prime and most well-known Docker registry is Docker Hub, run by the Docker organization and community and featuring thousands of images that fulfill anywhere from very general to laser-specific purposes, all easily findable and retrievable. Docker Hub can be accessed at https://registry.hub.docker.com.

Thin vs. Thick

When allocating storage for VMs, there are two main possibilities:

• Thin provisioning: With this type of provisioning, the virtual disk size is declared during setup, but the entirety of the storage space is not allocated or marked as “in use”; only that which is actually needed plus a small margin is marked as “in use.” The amount of actual storage used correlates to actual files written to the disk, and more space is allocated on an as-needed basis.

• Thick provisioning: This method involves preallocating or marking as being “in use” the full amount of space that is specified in the virtual disk configuration. There is no time spent on growing or shrinking the allocated space; it’s dedicated at the start.

The upside of using thin provisioning is that you can mark a virtual disk to be a certain size, but you don’t have to dedicate that space until actual writes to that virtual disk happen. The downside is that it is possible to overallocate the available space, and if you then suddenly want the full space, you can quickly run out of the hosting system’s actual storage.

The upside of using thick provisioning is that once a virtual machine’s disk is provisioned, the VM marks that amount as being used, and you don’t need to spend time trying to calculate or find space for new files; the space is there and ready to go. The downside of this method is that all the virtual disk space allocated is marked as used, and you can’t crowd more VMs on a machine that has no space remaining.

Persistent Volumes

When you virtualize Kubernetes, the storage volumes are tied to the pod or unit of computation/application. When the pod is deleted, the storage that was allocated is automatically lost unless you configure persistent volumes.

With persistent volumes, the life cycle or length of existence of the storage volumes a pod has access to is completely independent of the pod’s life cycle, which can be extremely variable. This allows for the use of persistent data between pods, and the life or death of an individual pod will not have any effect on the lifetime of the persistent volume.

Blobs and Blocks

Blobs and blocks can be used in the world of virtualization storage based on the storage need.

A BLOB is a binary large object. In Microsoft Azure, for example, there are block blobs, which are blobs containing blocks that are limited to 64MB in size; there can’t be more than 50KB blocks in a given block blob. Block blobs are ideal for such uses as streaming uploads or large file commits, where the pieces are uploaded in parallel or semi-parallel and assembled when they are committed to the storage device.

Another type of blob is a page blob, in which each page can be up to 512 bytes; a page blob can hold a maximum of 1TB of pages. Page blobs are great for storing things like HTML pages or storage files for small random read and write operation types, as the unit of read and write is a page, or 512 bytes.

Bridging

With bridged networking, a virtual machine’s network interface, which is of course software, is tied to the actual host machine’s Ethernet or other adapter via a virtual Ethernet switch (which on VMware is VMNet0 by default); the adapter of the VM appears to be a full network client or citizen, and it gets an IP address with the same subnet as the host’s adapter. The upside is that the VM is considered to be a full participant on the network; the downside is that because it’s a full participant, it uses up an IP address. Given that there might be a lot of VMs on a virtualization host system, bridging can use a lot of IP addresses for not much benefit.

Overlay Networks

An overlay network involves the layering of a more specific or purpose-driven additional layer of networking and protocols over an underlying network.

For example, the Internet was initially created to overlay the physical phone company network and conduct all its business on top of—but separately from—the underlying infrastructure.

An interesting point is that now the tables have turned, and because of the widespread use of Voice over IP (VoIP), the phone network of today is actually an overlay of the Internet infrastructure.

NAT

The direct opposite of a bridged connection is network address translation (NAT), in which a VM is consigned to a private virtual network that is typically in the 10.0.0.0, 172.16.0.0, or a 192.168.0.0 range and uses a NAT device or object to convert its local-only IP address into something that can be sent across the wide area network. The main advantages of this method are that it further obscures the VM from the dangers of the outside network, and it uses no extra IP addresses. Each and every VM can be on its own virtual network behind the NAT function, although you can have two or more VMs on the same virtual private address scheme and communicating with each other.

Local

With local networking, also known as host-only networking, the network that the VM is on is effectively restricted to local traffic only, and typically it communicates only with the virtualization host via a virtual Ethernet switch.

Dual-homed

One of the main advantages of having VMs running is that you can segregate tasks or services to a particular VM and have that VM provide those services over the network.

A problem that can affect a virtualization host system is that it might have a number of VMs all using NAT or bridged networking, and the single Ethernet interface on the virtualization host can become a bottleneck. Dual-homing prevents such a bottleneck. With dual-homing, you configure two Ethernet devices for VMs to use and intelligently assign VMs or even blocks of VMs to use a given Ethernet device as their network access device. This way, the Ethernet interfaces don’t become the bottleneck or cause performance issues.