Server Virtualization

This section describes server virtualization technologies such as virtual machines, containers, and virtual switching.

Server virtualization is the process of using software to create multiple independent virtual servers (virtual machines) or multiple independent containerized operating systems (containers) on a physical x86 server.
Network functions virtualization (NFV) is the process of virtualizing specific network functions, such as a firewall function, into a virtual machine (VM) so that they can be run in common x86 hardware instead of a dedicated appliance.
VMs and containers increase the overall efficiency and cost-effectiveness of a server by maximizing the use of the available resources.

Virtual Machines

VM is a software emulation of a physical server with an operating system. The virtualization software that creates VMs and performs the hardware abstraction to allow multiple VMs to run concurrently is known as a hypervisor.

Type 1: This type of hypervisor runs directly on the system hardware. It is commonly referred to as “bare metal” or “native.” Examples include: VMware vSphere, Microsoft Hyper-V, Citrix XenServer, and Red Hat Kernel-based Virtual Machine (KVM).
Type 2: This type of hypervisor (for example, VMware Fusion) requires a host OS to run. This is the type of hypervisor that is typically used by client devices.

Virtual Machines Advantages

One key capability of VMs is that they can be migrated from one server to another while preserving transactional integrity during movement. This has many advantages. For example, if a physical server needs a memory upgrade, the VMs can be migrated to other servers with no downtime. Another advantage is that it provides high availability. For example, if a server fails, the VMs can be spun up on other servers in the network, as illustrated in Figure 27-3.

Figure 27-3 VM Migration

Containers

A container is an isolated environment where containerized applications run. It contains the application, along with the dependencies that the application needs to run. Though they have similarities to VMs, containers are not the same as VMs.
Figure 27-4 shows a side-by-side comparison of VMs and containers. Notice that each VM requires an OS and that containers all share the same OS while remaining isolated from each other.

Figure 27-4 Side-by-Side Comparison of VMs and Containers

Differences Between Containers and VMs

A VM includes a guest OS, which typically comes with a large number of components (including executables, libraries, and dependencies) that are really not required for the application to run.
Containers share the underlying resources of the host operating system and do not include a guest OS, as VMs do. Containers are lightweight (small in size).
The application, along with the specific dependencies (binary files and libraries) that it needs to run, are included within the container.
Containers originate from container images, a file created by a container engine that includes the application code along with its dependencies.
A container does not try to virtualize a physical server as a VM does. Instead, the abstraction is the application or the components that make up the application.
When a VM starts, the OS needs to load first, and once it is operational, the application in the VM can then start and run. This whole process usually takes minutes.
When a container starts, it leverages the kernel of the host OS, which is already running, and it typically takes a few seconds to start.

Virtual Switching

A virtual switch (vSwitch) is a softwarebased Layer 2 switch that operates like a physical Ethernet switch.
A vSwitch enables VMs to communicate with each other within a virtualized server and with external physical networks through the physical network interface cards (pNICs).

Multiple vSwitches can be created under a virtualized server, but network traffic cannot flow directly from one vSwitch to another vSwitch within the same host, and the vSwitches cannot share the same pNIC.

Figure 27-5 Virtualized Server with vSwitches

Figure 27-5 illustrates a virtualized server with three vSwitches connected to the virtual network interface cards (vNICs) of the VMs as well as the pNICs. vSwitch1 and vSwitch3 are linked to pNIC 1 and pNIC 3, respectively, to access the physical network, whereas vSwitch2 is not linked to any pNICs.

Distributed Virtual Switching Benefits

One of the downsides of standard vSwitches is that every vSwitch that is part of a cluster of virtualized servers needs to be configured individually in every virtual host. This problem is solved by using distributed virtual switching, a feature that aggregates vSwitches together from a cluster of virtualized servers and treats them as a single distributed virtual switch. Benefits include:

Centralized management of vSwitch configuration for multiple hosts in a cluster
Migration of networking statistics and policies with virtual machines during a live VM migration
Configuration consistency across all the hosts that are part of the distributed switch

Like VMs, containers rely on vSwitches (also known as virtual bridges) for communication within a node (server) or the outside world.

Figure 27-6 Container Bridging

Figure 27-6 illustrates how every container created by Docker is assigned a virtual Ethernet interface (veth) on Docker0.

Other useful information:

Join the conversation