2.1.1 What Is Virtualization?

In computing, virtualization refers to the act of creating a virtual (rather than actual) version of something, including virtual computer hardware platforms, storage devices, and computer network resources. Virtualization is similar to abstraction but it does not always hide low layer's details. A real system is transformed so that it appears to be different. Moreover, virtualization can be applied not only to a subsystem, but also to an entire machine, e.g., VM, virtual network. Generally speaking, virtualization is about creating illusions, e.g., in Fig. 2.2, two files appear on separate hard disks, each of which is actually a partition on an actual hard disk. Thus, a virtualized system's interface and resources are mapped onto interface and resources of another (“real”) system; and virtualization provides a different interface and/or resources at the same level of abstraction.

Virtualization provides many benefits that are summarized as follows:

•  Resource optimization – satisfying the real needs of users and applications so that the available computing power, storage space, and network bandwidth can be used much more effectively. Computers no longer need to be idle or perform below their capabilities because there are fewer connected users, or because the hosted application happens to be less demanding than the server can handle.

•  Server consolidation – providing efficient usage of computer server resources in order to reduce the total number of servers or server locations that an organization requires. For organizations that own hundreds or thousands of servers, consolidation can dramatically reduce the need for floor space, HVAC, power, and colocation resources. This means that the cost of ownership is reduced significantly, since fewer physical servers and less floor and rack space are required, which in turn leads to less heat and lower power consumption, and ultimately a smaller carbon footprint.

•  Application consolidation – decreasing the number of vendors, licenses, home-built applications can significantly reduce a system's complexity. Moreover, it will help replace legacy applications, and thus make it easier to find technicians with the skills (and desire) to support them.

•  Sandboxing – separating running programs, which is a security mechanism in computer security. It is often used to execute untested or untrusted programs or code, possibly from unverified or untrusted third parties, suppliers, users or websites, without risking harm to the host machine or operating system (OS).

•  Multiple execution environments – bringing multifaceted benefits such as isolating application functions for security purpose, providing redundancy for backup, load sharing, and fail-safe application features, etc. Since a VM is independent and isolated from other servers, programmers can run software without having to worry about affecting other applications, or external components affecting the execution of their codes.

•  Virtual hardware – reducing the complexity of software development to interact with hardware-dependent programming languages, and allowing application to interact with physical system using simplified or universal software interfaces.

•  Debugging – making it easier to replicate the software/system running state for debugging purposes.

•  Software migration (mobility) – offering software migration as several important cloud services are based on it. For example, live migration consists of migrating the memory content of the VM, maintaining access to the existing storage infrastructure containing the VM's stored content while providing continuous network connectivity to the existing network domain. The existing VM transactions can be maintained and any new transaction will be allowed during any stage of live migration, thereby providing continuous data availability.

•  Appliance (software) – enabling software plug-and-play feature and working as appliances that can be easily enabled and disabled, and applied at any network segment or interfaced to existing services in a cloud-based service platform.

•  Testing/Quality assurance – offering software developers isolated, constrained, test environments in the form of VMs. Rather than purchasing dedicated physical hardware, VMs can be created on the existing hardware. For testers, they can create unlimited number of user configurations on their physical machines and choose the most suitable configuration at each stage. This gives the possibility to experiment with potentially incompatible applications and perform testing with different user profiles. Moreover, testing will be hardware independent, portable, and backup and replication will be easy.

For computer virtualization, there are typically two types of system involved: the virtualized system is called a guest system, and the “real” system is called a host system. Multiple layers of virtualized host systems is also an option.

The host transformation to a (set of) different virtualized system(s) can be represented as an isomorphic mapping of the guest system to the host system. In Fig. 2.3, the state transition between the host and guest systems is presented, where the $S_i$, $S_j$ are states in a system, e is an operation sequence modifying $S_i$ to $S_j$, V is a function mapping guest states to host states $S_i^{\prime }$, $S_j^{\prime }$, and $e^{\prime }$ is an operation sequence corresponding to e. This model can be applied for both virtualization and abstraction, where the same isomorphism can be used to depict both of them; with the main difference being that virtualization does not necessarily hide details.

In essence, virtualization describes a framework that combines or divides “computing” resources to present a transparent view of one or more environments composed by hardware or software partitioning (or aggregation) with partial or complete machine simulation or/and emulation in a time-sharing fashion. In general, a virtualization is constructed by a mapping between the combined or divided “computing” resource that can be an M-to-N mapping (i.e., M “real” resources and N “virtual” resources). For example, VM is an M-to-N mapping, grid computing is an M-to-1 mapping, and network multitasking is a 1-to-N mapping.

As shown in Fig. 2.4, virtualization is generally realized by a “Hypervisor” or “Virtual Machine Monitor (VMM)” on a single physical server, which is a piece of computer software, firmware or hardware that creates and runs VMs. A computer on which a hypervisor is running one or more VMs is defined as a host machine. Each VM is called a guest machine. The hypervisor presents the guest OS with a virtual operating platform and manages the execution of the guest OS. Multiple instances of a variety of OS may share the virtualized hardware resources. For a cloud computing system, the virtualization layer is usually implemented through a system of software packages, such as OpenStack [220], which are used to virtualize clusters of physical servers and provision multiple VMs across underlying physical servers interconnected by high-speed networks.

In addition to computer system virtualization, the virtualization concept can also be presented within a host (or computer), on a network (e.g., virtual LAN), or on a networked system (i.e., multiple hosts for setting up cloud IaaS), which will be discussed in Section 2.5.

2.1.2 Abstraction vs. Virtualization

Virtualization is an important technique for establishing modern cloud computing services. However, it is easy to confuse with another overly used concept – abstraction. In short, abstraction is about hiding details, and involves constructing interfaces to simplify the use of the underlying resource (e.g., by removing details of the resource's structure). For example, a file on a hard disk that is mapped to a collection of sectors and tracks on the disk. We usually do not directly address disk layout when accessing the file. Concrete is the opposite of abstract. For example, software and development goes from concrete, e.g., the actual binary instructions, to abstract, e.g., assembly to C to Java to a framework like Apache Groovy [54] to a customizable Groovy add-on. For computer virtualization solutions, hardware no longer exists for the OS. At some level it does, on the host system, but the host system creates a virtualization layer that maps hardware functions, which allows an OS to run on the software rather than the hardware.

Besides abstraction, two additional concepts are also quite frequently used with the concept of virtualization: replication is to create multiple instances of the resource (e.g., to simplify management or allocation); and isolation is to separate the uses which clients make of the underlying resources (e.g., to improve security).

2.2.1 First Classification: Host Internal Process Model

The first virtualization approach is based on a computer's (or machine's) internal process model as shown in Fig. 2.5. From the process perspective, a “machine” is a combination of OS and user level processes involving user-level logical memory address space assigned to the process, user-level registers and instructions for program execution, I/O part of machine visible only through OS, interaction via OS calls, Application Binary Interface (ABI) providing process/machine interface, etc. We can broadly classify virtualization based on three different levels of a machine's internal processes.

ISA (Instruction Set Architecture) based virtualization:

•  division between hardware and software;

•  subparts – user ISA which describes parts of ISA visible to applications, and system ISA which describes parts of the ISA visible to supervisor software. System ISA can also employ user ISA components;

•  software compatibility – software built to a given ISA can run on any hardware that supports that ISA.

Application Binary Interface (ABI) based virtualization:

•  provides programs with access to hardware resources and services;

•  major components – set of all user instructions;

•  system calls – indirect interaction with hardware resources, and OS operations are performed on behalf of user programs, which often includes security checks (w.r.t., access privileges);

•  support for portability – binaries compiled to a specific ABI can run unchanged on a system with the same ISA and OS.

API based virtualization:

•  abstracts from the details of service implementations;

•  usually is defined with respect to a High-Level Language (HLL) such as a standard library to invoke OS services, which are typically defined at a source code level;

•  support for portability – where software using a given API can be ported to other platforms by recompilation.

2.2.2 Second Classification: ISA, System Calls, and APIs

The second classification broadly covers most of virtualization techniques at different levels of implementation within a computer. Conceptually a VM represents an operating environment for a set of user-level applications, which includes libraries, system call interface/service, system configurations, daemon processes, and file system state. There can be several levels of abstraction where virtualization can take place [79]: instruction set level, hardware abstraction layer (HAL), OS level (system call interface), user-level library interface, or in the application level, as shown in Fig. 2.6. Whatever the level of abstraction may be, the general phenomenon still remains the same; it partitions the lower-level resources using some novel techniques to map to multiple higher level VMs transparently.

2.2.3 Third Classification: Two Types of Hypervisor

As shown in Fig. 2.7A, a process VM is capable of supporting an individual process virtualizing software. For example, the VM can be placed at ABI, on top of OS and hardware. It emulates both user-level instructions and OS calls. As shown in Fig. 2.7B, a system VM provides a complete system environment that can support a “guest OS” with (probably) many user processes. It is placed between underlying hardware and conventional software, and it also provides ISA translation. Another alternate approach is using hosted VM, where virtualizing software is built on top of an OS.

A hypervisor (or VMM – Virtual Machine Monitor) is a software layer that allows several VMs to run on a physical machine. A “hypervisor” is the essence of the cloud technology that we all enjoy today. Nowadays, there exist many stable and feature-rich hypervisors: RetHat KVM, VMware, Microsoft Hyper-V, Oracle VirtualBox, and Xen, to name several popular ones. One of the main differences between hypervisor platforms is their classification as “Type 1” or “Type 2” hypervisor, which are presented in Fig. 2.8.

Type 1 hypervisors directly run on the physical hardware. They control the hardware as well as manage the VMs. Type 1 hypervisors are also termed bare metal hypervisors. Type 2 hypervisors run as an application on an existing OS (a.k.a., host OS), which is installed on the bare metal. Here, there is an added complexity of the guest OS calls needing to traverse via the host OS stack before they reach the hardware.

Virtualization for cloud computing

As presented in previous classifications of virtualization approaches, there are several different breeds of virtualization, though all of them share one thing in common – the end result is a virtualized simulation of a device or resource. In other words, virtualization is generally accomplished by dividing a single piece of hardware into two or more “segments.” Each segment operates as its own independent environment.

In Cloud Computing, the cloud determines how virtualized resources are allocated, delivered, and presented. Cloud computing is built on virtualization technologies. The relation between cloud and virtualization can be viewed as follows: virtualization can exist without the cloud, but cloud computing cannot exist without virtualization. Virtualization is not necessary to create a cloud environment, but it enables rapid scaling of resources in a way that nonvirtualized environments find hard to achieve.

As shown in Fig. 2.9, it presents the representation between the virtualization of a computer and the virtualization of cloud resources. It shows that both infrastructures are similar in terms of the resource management and control (CTL), and the difference lies in the scale of the management resource. The underpinning for the majority of clouds is a virtualized infrastructure (also called cloud orchestration layer), in which virtualization is used to establish a pool of infrastructure resources, which can also provide the basic building to enhance agility and flexibility. Existing cloud resource management solutions primarily focus on how to virtualize cloud servers' computing, networking, and storage resources.

2.3.1 Docker: OS Level Virtualization

OS level virtualization is a server-virtualization method where the kernel of an OS allows for multiple isolated user-space instances, instead of just one. Such instances (sometimes called containers, software containers, Virtualization Engines (VE), Virtual Private Servers (VPS), or jails) may look and feel like a real server from the point of view of its owners and users.

On Unix-like OS, one can see this technology as an advanced implementation of the standard chroot [11]¹ mechanism. In addition to isolation mechanisms, the kernel often provides resource-management features to limit the impact of one container's activities on other containers.

Operating-system-level virtualization is commonly used in virtual hosting environments, where it is useful for securely allocating finite hardware resources amongst a large number of mutually-distrusting users. System administrators may also use it, to a lesser extent, for consolidating server hardware by moving services on separate hosts into containers on a server.

Other typical scenarios include separating several applications to separate containers for improved security, hardware independence, and added resource management features. The improved security provided by the use of a chroot mechanism, however, is nowhere near ironclad. Operating-system-level virtualization implementations capable of live migration can also be used for dynamic load balancing of containers between nodes in a cluster.

Operating-system-level virtualization usually imposes little to no overhead, because programs in virtual partitions use the OS's normal system call interface and do not need to be subjected to emulation or be run in an intermediate VM, as is the case with whole-system virtualizers (such as VMware ESXi, QEMU, or Hyper-V) and parallel virtualizers (such as Xen or UML). This form of virtualization also does not require support in hardware to perform efficiently.

Operating-system-level virtualization is not as flexible as other virtualization approaches since it cannot host a guest OS different from the host one, or a different guest kernel. For example, with Linux, different distributions are fine, but other OS such as Windows cannot be hosted.

Docker union file system

Union File System (UnionFS) is a file system service for Linux, FreeBSD, and NetBSD, which implements a union mount³ for other file systems. UnionFS represents file system by grouping directories and files in branches. Docker Engine uses UnionFS to provide the building blocks for containers.

A Docker image is made up of file systems layered over each other. Images can be layered on top of one another. The image below is called the parent image and an application can traverse each layer until reaching the bottom of the image stack where the final image is called the base image. Finally, when a container is launched from an image, Docker mounts a read–write file system on top of any layers below. The processes a Docker container can run and execute are shown as yellow boxes in Fig. 2.10.

When Docker first starts a container, the initial read–write layer is empty. When changes occur, they are applied to this layer. For example, if a user wants to change a file, then that file will be copied from the read-only layer below into the writable layer. The read-only version of the file will still exist, but now be hidden underneath the copy.

This pattern is traditionally called copy-on-write and is one of the features that makes Docker very attractive for building cloud services. This is because each read-only image layer is read-only and this image never changes; when a container is created, Docker builds from the stack of images and then adds the read–write layer on top; and that layer, combined with the knowledge of the image layers below it and some configuration data, forms the container.

How is Docker different from VMs?

Containers have similar resource isolation and allocation benefits as VMs but use a different architectural approach, allowing them to be more portable and efficient as shown in Fig. 2.11.

Each VM includes applications, necessary binaries and libraries, and an entire guest OS – all of which may be tens of GBs in size. Containers include applications and all of their dependencies, but share the kernel with other containers. They run as an isolated process in userspace on the host OS. They are also not tied to any specific infrastructure, i.e., Docker containers can run on any computer, on any infrastructure and in any cloud.

2.3.2 OSGi: Application Level Virtualization Library

OSGi is another popular virtualized program running environment, which has been widely adopted. It is a framework for Java in which units of resources called bundles can be installed. Bundles can export services or run processes, and have their dependencies managed, such that a bundle can be expected to have its requirements managed by the container. Each bundle can also have its own internal classpath,⁴ so that it can serve as an independent unit, should that be desirable. All of this is standardized such that any valid OSGi bundle can theoretically be installed in any valid OSGi container.

OSGi architecture

The OSGi specification describes a modular system and a service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java/VM environments. Applications or components, coming in the form of bundles for deployment, can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot; management of Java packages/classes is specified in great detail. Application life cycle management is implemented via APIs that allow for remote downloading of management policies. The service registry allows bundles to detect the addition of new services, or the removal of services, and adapt accordingly.

Any framework that implements the OSGi standard provides an environment for the modularization of applications into smaller bundles. Each bundle is a tightly coupled, dynamically loadable collection of classes, jars, and configuration files that explicitly declare their external dependencies (if any).

The framework is conceptually divided into the following areas, as shown in Fig. 2.12:

•  Bundles – Bundles are normal jar components with extra manifest headers.

•  Services – The services layer connects bundles in a dynamic way by offering a publish–find–bind model for Plain Old Java Interfaces (POJI) or Plain Old Java Objects (POJO).

•  Services Registry – The API for management services.

•  Life-Cycle – The API for life cycle management (install, start, stop, update, and uninstall) of bundles.

•  Modules – The layer that defines encapsulation and declaration of dependencies (how a bundle can import and export code).

•  Security – The layer that handles the security aspects by limiting bundle functionality to predefined capabilities.

•  Execution Environment – It defines what methods and classes are available in a specific platform.

OSGi bundles

An OGSi bundle is a JAR file that has the following features and capabilities [223]:

•  It contains the resources necessary to provide some functionality. These resources may be class files for the Java programming language, as well as other data such as HTML files, help files, icons, and so on. A bundle JAR file can also embed additional JAR files that are available as resources and classes. This is, however, not recursive.

•  It contains a manifest file describing the contents of the JAR file and providing information about the bundle. This file uses headers to specify information that the framework needs to install correctly and activate a bundle. For example, it states dependencies on other resources, such as Java packages, that must be available to the bundle before it can run.

•  It can contain optional documentation in the OSGI-OPT directory of the JAR file or one of its subdirectories. Any information in this directory is optional. For example, the OSGI-OPT directory is useful to store the source code of a bundle. Management systems may remove this information to save storage space in the OSGi framework.

With the installation of a bundle in the OSGi runtime the bundle is persisted in a local bundle cache. The OSGi runtime then tries to resolve its dependencies. If all required dependencies are resolved, the bundle is in the RESOLVED status otherwise it stays in the INSTALLED status. In case several bundles exist which can satisfy the dependency, the bundle with the highest valid version is used. If the versions are the same, the bundle with the lowest unique identifier is used. Every bundle gets this identifier assigned by the framework during the installation. When the bundle starts, its status is STARTING. After a successful start, it becomes ACTIVE. This life cycle is depicted in Fig. 2.13.

OSGi services

In the OSGi framework, bundles are built around a set of cooperating services available from a shared service registry. Such an OSGi service is defined semantically by its service interface and implemented as a service object.

The service interface should be specified with as few implementation details as possible. OSGi has specified many service interfaces for common needs and will specify more in the future. The service object is owned by, and runs within, a bundle, as shown by the dotted line in Fig. 2.14. This bundle must register the service object with the framework service registry so that the service's functionality is available to other bundles under control of the framework.

Dependencies between the bundle owning the service and the bundles using it are managed by the framework. For example, when a bundle is stopped, all the services registered with the framework by that bundle must be automatically unregistered.

The framework maps services to their underlying service objects, and provides a simple but powerful query mechanism that enables a bundle to request the services it needs. The framework also provides an event mechanism so that bundles can receive events of services that are registered, modified, or unregistered.

2.3.3 Comparison to Hypervisor Virtualization

Compared to hypervisor-based virtualization, the OS level virtualization or containers have the following differences:

•  Fast deployment – The full VM starts in minutes, whereas the containers starts guests in seconds. The containers avoid initializing the guest OS, which makes the guests start much faster.

•  Less resource requirement – Since the full virtualization allocates resources for each guest OS, it requires much more resources. On the other hand, guests in the containers either share the OS with the host or even no OS, like OSGi, thus, the resource consumption is much less.

•  Flexibility – Some containers provide start and stop features, which is a lightweight operation to freeze and resume guests and keep the guest state in memory. The full VM freeze and resume function usually saves the guest state in the disk due to the large VM state image, whose cost is much higher than the containers.

•  Forensic – The container's state is easy to access by the host, since guests share some resources with the host. Full VM state is much harder to get because the host has to interpret a full memory image and get to know the other OS state, which is not that easy.

2.4.1 Bring Your Own Device (BYOD)

The proliferation of devices such as tablets and smart phones, which are now used by many people in their daily lives, has led to a number of companies, such as IBM, to allow employees bring their own devices to work, due to perceived productivity gains and cost savings. In order to achieve increased adoption and sustainability of BYOD schemes within the enterprise, mobile virtualization is rapidly becoming an attractive choice because it provides both employee and enterprise flexibility while addressing the privacy concerns of the user and meeting the organizations security requirements. On the other side of the ecosystem, the device makers and carriers will benefit from mobile virtualization because they will be able to more easily replicate the features found in various devices and also deliver more features at a lower cost. Enterprises that allow employees to use their BYOD devices must also put in place policies that govern how those devices will be used and how they will be managed while maintaining end-user flexibility [152].

BYOD is also called bring your own technology (BYOT), bring your own phone (BYOP), and bring your own PC (BYOPC), and refers to the policy of permitting employees to bring personally owned mobile devices (laptops, tablets, and smart phones) to their workplace, and to use those devices to access privileged company information and applications. BYOD usage is primarily driven by perceived enjoyment. The phenomenon is commonly referred to as IT consumerization.

Mobile separation techniques

A number of technologies for mobile separation have been developed over the last few years, but most of them revolve around two types of technology: hypervisor separation and container-based separation, as shown in Fig. 2.15.

Mobile separation via hypervisors provides the ability to run two or more instances of an OS on the same phone, thereby giving the ability to run personal applications and services on one OS and business services on the more secure OS. In the case of mobile containers, separation is achieved at the application level via the OS by any or all of the following: intercepting specific OS function calls, managing user permissions, enforcing certain security policies, and device management features.

Hypervisor approaches to mobile separation have the advantage of better protection from risks such as rooted phones, because a user rooting his personal OS instance would not put at risk the corporate OS instance. However, such hypervisor approaches will typically have a higher level of performance or battery impact on mobile devices and can also be more expensive to maintain because of the requirement to develop and secure an entire corporate OS image. Container approaches often have the advantage of a more seamless user experience, as some aspects of personal and business use can interact in ways that separate OS instances never could. The trade-off here is typically the need to manage the underlying OS instance to protect the application layer container from attacks at the root of the device.

2.4.2 KVM over ARM

Historically, the ARM architecture is not virtualizable, because there are a number of sensitive instructions which do not trap when they are executed in an unprivileged mode. However, the most recent 32-bit ARM processors, like the Cortex-A15, include hardware support for virtualization as an ARMv7 architectural extension. A number of research projects have attempted to support virtualization on ARM processors without hardware virtualization support, but they require various levels of paravirtualization and have not been stabilized. KVM/ARM is designed specifically to work on ARM processors with the virtualization extensions enabled to run unmodified guest OS.

The ARM hardware extensions differ quite a bit from their x86 counterparts. A simplified view of the ARM CPU modes is that the kernel runs in SVC mode and user space runs in USR mode. ARM introduced a new CPU mode for running hypervisors called HYP mode, which is a more privileged mode than SVC mode. An important characteristic of HYP mode, which is central to the design of KVM/ARM, is that HYP mode is not an extension of SVC mode, but a distinct mode with a separate feature set and a separate virtual memory translation mechanism. For example, if a page fault is taken in HYP mode, the faulting virtual address is stored in a different register in HYP mode than in SVC mode. As another example, for the SVC and USR modes, the hardware has two separate page table base registers, which are used to provide the familiar address space split between user space and kernel. HYP mode only uses a single page table base register and therefore does not allow the address space split between user mode and kernel.

As ARM CPUs become increasingly common in mobile devices and servers, there is a growing demand for providing the benefits of virtualization for ARM-based devices. KVM/ARM [90] introduces split-mode virtualization, allowing a hypervisor to split its execution across CPU modes to take advantage of CPU mode-specific features. This allows KVM/ARM to leverage Linux kernel services and functionality to simplify hypervisor development and maintainability while utilizing recent ARM hardware virtualization extensions to run application workloads in guest OS with comparable performance to native execution. KVM/ARM has been successfully merged into the mainline Linux 3.9 kernel, ensuring that it will gain wide adoption as the virtualization platform of choice for ARM.

2.5.1 From Network Overlay to Virtual Networks

An overlay network is a computer network that is built on top of another network. An example is shown in Fig. 2.16. Nodes in the overlay network can be thought of as being connected by virtual or logical links, each of which corresponds to a path, perhaps through many physical links, in the underlying network. For example, distributed systems such as peer-to-peer networks are overlay networks because their nodes run on top of the Internet. The Internet was originally built as an overlay upon the telephone network, while today (through the advent of Voice over IP (VoIP)), the telephone network is increasingly turning into an overlay network built on top of the Internet.

Overlay networks builds the foundation of virtual networks and they run as independent virtual networks on top of a physical network infrastructure. These virtual network overlays allow resource providers, such as cloud providers, to provision and orchestrate networks alongside other virtual resources. They also offer a new path to converged networks and programmability.

A virtual network is a computer network that consists, at least in part, of virtual network links. A virtual network link is a link that does not consist of a physical (wired or wireless) connection between two computing devices but is implemented using methods of NV.

The two most common forms of NV are protocol-based virtual networks, such as Virtual LANs (VLANs) [7], Virtual Networks (VNs) and Virtual Private Networks (VPNs) [51], Virtual Private LAN Services (VPLS) [173], and virtual networks that are based on virtual devices (such as the networks connecting VMs inside a hypervisor). In practice, both forms can be used in conjunction.

VLANs are logical local area networks (LANs) based on physical LANs as shown in Fig. 2.16. A VLAN can be created by partitioning a physical LAN into multiple logical LANs using a VLAN ID. Alternatively, several physical LANs can function as a single logical LAN. The partitioned network can be on a single router, or multiple VLANs can be on multiple routers just as multiple physical LANs would be.

A VPN consists of multiple remote end-points (typically routers, VPN gateways of software clients) joined by some sort of tunnel over another network, usually a third-party network. Two such end points constitute a “Point to Point Virtual Private Network” (or a PTP VPN). Connecting more than two end points by putting in place a mesh of tunnels creates a “Multipoint VPN.”

A VPLS is a specific type of Multipoint VPN. VPLS are divided into Transparent LAN Services (TLS) and Ethernet Virtual Connection Services. A TLS sends what it receives, so it provides geographic separation, but not VLAN subnetting. An Ethernet Virtual Connections (EVCS) adds a VLAN ID, so it provides geographic separation and VLAN subnetting.

A common example of a virtual network that is based on virtual devices is the network inside a hypervisor where traffic between virtual servers are routed using virtual switches (vSwitches) along with virtual routers and virtual firewalls for network segmentation and data isolation. Such networks can use nonvirtual protocols such as Ethernet as well as virtualization protocols such as the VLAN protocol IEEE 802.1Q [146].

2.5.2 Virtual Networks

The two most common forms of network virtualization are protocol-based virtual networks (such as VLANs, VPNs, and VPLSs) and virtual networks that are based on virtual devices (such as the networks connecting VMs inside a hypervisor). Several popular virtual networking protocols are presented as follows:

•  L2TP (Layer 2 Tunneling Protocol) is a tunneling protocol used to support VPNs or as part of the delivery of services by ISPs. It does not provide any encryption or confidentiality by itself. Rather, it relies on an encryption protocol that it passes within the tunnel to provide privacy. The entire L2TP packet, including payload and L2TP header, is sent within a User Datagram Protocol (UDP) datagram. It is common to carry PPP sessions within an L2TP tunnel. L2TP does not provide confidentiality or strong authentication by itself. IPsec is often used to secure L2TP packets by providing confidentiality, authentication and integrity. The combination of these two protocols is generally known as L2TP/IPsec.

•  PPP (Point-to-Point Protocol) is a data link (layer 2) protocol used to establish a direct connection between two nodes. It connects two routers directly without any host or any other networking device in between. It can provide connection authentication, transmission encryption, and compression. PPP is used over many types of physical networks including serial cable, phone line, trunk line, cellular telephone, specialized radio links, and fiber optic links such as SONET. PPP is also used over Internet access connections. Internet service providers (ISPs) have used PPP for customer dial-up access to the Internet, since IP packets cannot be transmitted over a modem line on their own, without some data link protocol.

•  VLAN (Virtual Local Area Networks) is any broadcast domain that is partitioned and isolated in a computer network at the data link layer. VLANs allow network administrators to group hosts together even if the hosts are not on the same network switch. This can greatly simplify network design and deployment, because VLAN membership can be configured through software. To subdivide a network into virtual LANs, one configures network equipment. Simpler equipment can partition based on physical ports, MAC addresses, or IP addresses. More sophisticated switching devices can mark frames through VLAN tagging, so that a single interconnect (trunk) may be used to transport data for multiple VLANs.

•  VXLAN (Virtual eXtensible LAN) is a network virtualization technology that attempts to improve the scalability problems associated with large cloud computing deployments. It uses a VLAN-like encapsulation technique to encapsulate layer 2 Ethernet frames within layer 4 UDP packets, using 4789 as the default IANA-assigned destination UDP port number. VXLAN endpoints, which terminate VXLAN tunnels and may be both virtual or physical switch ports, are known as VXLAN tunnel endpoints (VTEPs). It is an alternative of Generic Routing Encapsulation (GRE) protocol in cloud system to build private networks as layer 2 tunnels.

•  Generic Routing Encapsulation (GRE) is a communication protocol used to establish a direct, point-to-point connection between network nodes. Being a simple and effective method of transporting data over a public network, such as the Internet, GRE lets two peers share data they will not be able to share over the public network itself. GRE encapsulates data packets and redirects them to a device that deencapsulates them and routes them to their final destination. This allows the source and destination switches to operate as if they have a virtual point-to-point connection with each other (because the outer header applied by GRE is transparent to the encapsulated payload packet). For example, GRE tunnels allow routing protocols such as RIP and OSPF to forward data packets from one switch to another switch across the Internet. In addition, GRE tunnels can encapsulate multicast data streams for transmission over the Internet.

•  SSL (Secure Socket Layer) is a standard security technology for establishing an encrypted link between a server and a client – typically a web server (website) and a browser, or a mail server and a mail client (e.g., Outlook) by encrypting data above the transport layer. The SSL protocol has always been used to encrypt and secure transmitted data. For example, all browsers have the capability to interact with secured web servers using the SSL protocol. However, the browser and the server need what is called an SSL Certificate to be able to establish a secure connection, where SSL Certificates is constructed based on a key pair: a public and a private key, and a certificate that contains a public key digital signed by using a trusted third party's private key. A client can use the server's certificate to establish an encrypted connection.

•  IPSec (IP security) is a network protocol suite that authenticates and encrypts the packets of data sent over a network at the IP layer. IPsec includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys for use during the session. IPsec can protect data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host (network-to-host).

2.5.3 Software Defined Networking

Software-Defined Networking (SDN) is a new computer networking management framework that allows network administrators to manage network services through abstraction of lower-level functionalities. Moreover, it provides programmable APIs allowing computer networking applications to interact with networking functions based on predefined programming logic and network traffic situations. SDN is meant to address the fact that the static architecture of traditional networks does not support the dynamic, scalable computing and storage needs of more modern computing environments such as data centers. This is done by decoupling or disassociating the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane).

OpenFlow

SDN was commonly associated with the OpenFlow protocol [255] (for remote communication with network plane elements for the purpose of determining the path of network packets across network switches) since the latter's emergence in 2011.

OpenFlow is a Layer 2 communications protocol that gives access to the forwarding plane of a network switch or router over the network, as shown in Fig. 2.17. The OpenFlow pipeline of every OpenFlow switch contains multiple flow tables, each flow table containing multiple flow entries.

OpenFlow-compliant switches come in two types:

•  OpenFlow-only – supporting only OpenFlow operation, in those switches all packets are processed by the OpenFlow pipeline, and cannot be processed otherwise.

•  OpenFlow-hybrid – supporting both OpenFlow operation and normal Ethernet switching operation, i.e., traditional L2 Ethernet switching, VLAN isolation, L3 routing (IPv4 routing, IPv6 routing, etc.), ACL and QoS processing.

2.5.4 Network Function Virtualization

Network Function Virtualization (NFV) is a network architecture concept that uses the technologies of IT virtualization to virtualize entire classes of network node functions into building blocks that may connect, or chain together, to create communication services.

NFV relies upon, but differs from, traditional server-virtualization techniques, such as those used in enterprise IT. A Virtualized Network Function (VNF) may consist of one or more VMs running different software and processes, on top of standard high-volume servers, switches and storage devices, or even cloud computing infrastructure, instead of having custom hardware appliances for each network function.

The goal of NFV is to decouple network functions from dedicated hardware devices and allow network services that are now being carried out by routers, firewalls, load balancers, and other dedicated hardware devices to be hosted on VMs. Once the network functions are under the control of a hypervisor, the services that once require dedicated hardware can be performed on standard x86 servers.

This capability is important because it means that network administrators will no longer need to purchase dedicated hardware devices in order to build a service chain. Because server capacity will be able to be added through software, there will be no need for network administrators to overprovision their data centers which will reduce both capital expenses (CAPex) and operating expenses (OPex). If an application running on a VM required more bandwidth, for example, the administrator could move the VM to another physical server or provision another VM on the original server to take part of the load. Having this flexibility will allow an IT department to respond in a more agile manner to changing business goals and network service demands.

NFV is different from SDN but is complementary to it. When SDN runs on the NFV infrastructure, the SDN forwards the data packets from one network device to another while the network routing (control) functions run on a VM in, for example, a rack mount server. The NFV concept, which was presented by a group of network service providers at the Software Defined Network and OpenFlow World Congress in October 2012, is being developed by the ETSI Industry Specification Group (ISG) for Network Functions Virtualization.

2.6.1 Block Store

The Block Store is virtualized disks. For a computer system, the disks are connected to the south bridge chip on the motherboard, through which the disks can talk to the motherboard BIOS by various protocols. The typical disk protocols are (P)ATA, SATA, and SCSI. The SCSI is widely used to implement the virtualized block storage due to the popular iSCSI protocol. In essence, iSCSI allows two hosts to negotiate and then exchange SCSI commands using Internet Protocol (IP) networks. By doing this, iSCSI takes a popular high-performance local storage bus and emulates it over a wide range of networks, creating a storage area network (SAN).

Examples 

•  OpenStack Cinder. Cinder is a Block Storage service for OpenStack. It's designed to present storage resources to end users that can be consumed by the OpenStack Compute Project (Nova). This is done through the use of either a reference implementation (LVM) or plug-in drivers for other storage. The short description of Cinder is that it virtualizes the management of block storage devices and provides end users with a self-service API to request and consume those resources without requiring any knowledge of where their storage is actually deployed or on what type of device.

•  AWS EBS. Amazon Elastic Block Store (Amazon EBS) provides persistent block storage volumes for use with Amazon EC2 instances in the AWS Cloud. Each Amazon EBS volume is automatically replicated within an availability zone to protect you from component failure, offering high availability and durability. Amazon EBS volumes offer the consistent and low-latency performance needed to run. With Amazon EBS, you can scale your usage up or down within minutes – all while paying a low price for only what you provision.

2.6.2 File Store

The widely used Linux system has a feature to mount a remote file directory to a local file system, which is usually called NFS (network file system). The NFS server is actually a virtualized file store.

Examples 

•  OpenStack Manila implements the concept and vision for establishing a shared file system service for OpenStack. The File Share Service prototype provides coordinated access to shared or distributed file systems. While the primary consumption of file shares would be across OpenStack Compute instances, the service is also intended to be accessible as an independent capability in line with the modular design established by other OpenStack services. The design and prototype implementation provide extensibility for multiple back-ends (to support vendor or file system specific nuances/capabilities) but is intended to be sufficiently abstract to accommodate any of a variety of shared or distributed file system types. The team's intention is to introduce the capability as an OpenStack incubated project in the Juno time-frame, graduate it, and submit for consideration as a core service as early as the Kilo release.

•  NFS is a distributed file system protocol originally developed by Sun Microsystems in 1984, allowing a user on a client computer to access files over a computer network much like local storage is accessed. NFS, like many other protocols, builds on the Open Network Computing Remote Procedure Call (ONC RPC) system. The NFS is an open standard defined in Request for Comments (RFC), allowing anyone to implement the protocol.