\ Mobile Cloud Computing - Virtualization
Feature: Page (1) of 1 - 10/09/17

Mobile Cloud Computing - Virtualization

By Dr. Dijiang Huang and Dr. Huijun Wu

Great design is a multi-layered relationship between human life and its environment.
Naoto Fukasawa

We have been lately hearing a lot about virtualization whenever there has been a talk about cloud computing. Although most of us may have ourselves used virtual machines (VMs) in the past to solve a very different purpose altogether, most of us are not really sure what virtualization is and why it is so beneficial! Virtualization is a technology that combines or divides computing, storage, or networking resources to present one or many operating environments using methodologies like hardware and software partitioning or aggregation, partial or complete machine simulation, emulation, time-sharing, and others. Virtualization technologies find important applications over a wide range of areas such as server consolidation, secure computing platforms, supporting multiple operating systems (OS), kernel debugging and development, system migration, network management, etc., resulting in widespread usage. Most of them present similar operating environments to the end user; however, they tend to vary widely in the levels of abstraction they operate at and the underlying architecture. In this chapter, we will present the basic concepts of virtualization, and then we will focus on the meanings of virtualization in computer, mobiles, storage, and network.

2.1 The Concept of Virtualization

Generally speaking, virtualization is visible only superficially in cloud computing services. Servers typically take only about a few millionths of a second to service each request to the cloud depending on the communication speed and the computation capacity of cloud servers. Given such a short amount of time for serving the request, the amount of time the server machine is kept up and running relative to the time spent by it servicing the requests is much higher. This clearly demonstrates that a significant amount of energy is wasted per server in the process of keeping the servers up and ever-ready to service requests upon their arrival. Moreover, in addition to energy cost, the equipment cost for single-purpose service for each physical system also contributes to significant investment waste. Additionally, the issue of using one server for a single purpose instead of sharing it for multiple purposes needs to be addressed. So how exactly can cloud computing solutions eliminate this waste and thereby maximize the profits? The answer to this problem lies in virtualization.

Virtualization essentially means creating multiple, logical instances of software or hardware on a single physical hardware resource. The virtualization in a cloud system can be represented as shown in Fig. 2.1, where three main cloud computing resources, i.e., computing, networking, and storage, and applications can be virtualized through virtual machines, virtual networks, virtual hard drives, and containers, respectively. In a cloud system, various APIs are created to build a cloud orchestration layer to manage the virtualized cloud resources. This technique simulates the available hardware and gives every application for a cloud tennet running on top of it the feel that it is the unique holder of the resource. The details of the virtual, simulated environment are kept transparent to the application through various APIs. Organizations may use cloud computing technique to actually do away with many of their physical servers and map their functions onto multiple robust physical servers. The advantage here is the reduced cost of maintenance, reduced energy waste by repurposing multiple singlepurpose servers, which had high CPU idle percentage. Virtualization allows IT management use fewer physical servers, making maintenance much easier and cheaper.

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 harddisk. 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 Si, Sj are states in a system, e is an operation sequence modifying Si to Sj, V is a function mapping guest states to host states , and e 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 Classifications of Computer/Machine Virtualization

Computer-based virtualization is one of the most popular virtualization techniques. Based on the level of virtualization techniques, in the literature there are a few classification approaches and here we present them in the following sections.

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;
  • Figure 2.6: The second virtualization classification.
  • 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.

Instruction Set Architecture based Virtualization

ISA-based virtualization is implemented in software, and it usually emulates the ISA in software where it interprets and translates guest ISA to native (or host) ISA. It emulates hardware specific IN/OUT instructions to mimic a device, and certain level of device abstractions are provided. A typical ISA based virtualization is QEMU [29]. It supports multiple OS running on top of it and it is mainly used for software debugging and teaching purposes. The drawback of ISA based virtualization is due to its inefficiency in handling exceptions, translating instructions, and thus the performance is not good compared to other types of virtualization solutions. Two examples of ISA-based virtualization are presented as follows:

  • Bochs [175]. It is an open source x86 emulator which emulates the whole PC environment including x86 processor and most of the hardware (i.e., VGA, disk, keyboard, mouse, etc.). It also provides customizable BIOS, emulates power-up and reboot procedure. Bochs can run on multiple host ISAs such as x86, PowerPC, Alpha, Sun, and MIPS.
  • QEMU [29]. It is a full implementation of virtualized ISA supporting systems such as x86, ARM, PowerPC, SPARC, etc. It uses mmap() as the Memory Management Unit (MMU) function to create a new mapping in the virtual address space of the calling process. QEMU is a very popular ISA-based virtualization solution and can be run as userspace only, which is useful for cross-compilation and cross-debugging.
Hardware Abstraction Layer (HAL)

In computers, a hardware abstraction layer (HAL) is a layer of programming that allows a computer OS to interact with a hardware device at a general or abstract level rather than at a detailed hardware level. HAL can be called from either the OS's kernel or from a device driver. In either case, the calling program can interact with the device in a more general way than it would otherwise.

Virtualization at the HAL exploits the similarity in architectures of the guest and host platforms to cut down the interpretation latency. Virtualization technique helps map the virtual resources to physical resources and use the native hardware for computations in the VM. When the emulated machine needs to talk to critical physical resources, the simulator takes over and multiplexes appropriately. For such a virtualization technology to work correctly, the VM must be able to trap every privileged instruction execution and pass it to the underlying VMM to be taken care of. Hardware-level VMs tend to possess properties like high degree of isolation, i.e., both from other VMs as well as from the underlying physical machine, acceptance of the concept, support for different OSes and applications without requiring to reboot or going through the complicated dual-boot setup procedure, low risk, and easy maintenance. Typical HAL based virtualization solutions include many popular computer virtualization solutions such as VMware [233], Virtual PC [130], Denali [273], Plex86 [174], user model Linux [98], Cooperative Linux [50], etc.

In the third virtualization classification presented in Section 2.2.3, we will present two of the most popular HAL-based virtualization solutions, i.e., parallel virtualization (or bare-metal, or Type-I virtualization) and host-based virtualization (or Type-II virtualization), in detail.

Operating System Level

We present virtualization at a higher level in the machine stack (see Fig. 2.6) to minimize the redundancy of the OS requirement in VMs described above. The VMs at this level share the hardware as well as the OS on the physical machine and use a virtualization layer (similar to the VMMs in VMware) on top of the OS to present multiple independent and isolated machines to the user.

OS virtualization helps create virtualized layer of software on the top of host OS that resides above the hardware layer. Unlike other virtualization, they create an OS interfaces for applications to run, giving the feeling of a complete OS for the applications. Each virtualized environment has its own file system, system libraries, process tables, and network configuration. Since they create a self-contained environment, they are also known as "containers." Therefore, creating the software emulation of an entire OS in a physical server is the essence of OS virtualization. The main disadvantage of OS virtualization is that it supports only one OS as base and guest OS in a single server. A user has to choose a single OS such as Windows or Linux. All the OS in the container should be same version and should have same patch level of the base OS. If the base OS crashes, all virtual containers become unavailable. The main advantage of OS virtualization lies in that it offers highest performance and highest density of virtual environment since OS virtualization provides least overhead among all types of virtualization solutions.

An operating environment for an application consists of the OS, user-level libraries, other applications, some system specific data structures, a file system, and other environmental settings. If all of these are kept intact, an application would find it hard to notice any difference from that of a real environment. This is the key idea behind all the OS-level virtualization techniques, where a virtualization layer above the OS produces a partition per VM on demand that is a replica of the operating environment on the physical machine. With careful partitioning and a multiplexing technique, each VM can export a full operating environment and be fairly isolated from one another and from the underlying physical machine. Typical OS-based virtualization solutions also include many popular computer virtualization solutions such as Jail [154], Ensim [161], OpenVZ [73], Virtuozzo [225], etc.

Library (user-level API) Level

In most computing systems, applications are programmed using a set of APIs exported by a group of user-level library implementations. Such libraries are designed to hide the OS related nitty-gritty details to keep it simpler for normal programmers. However, this gives a new opportunity to the virtualization community. Examples include Wine [39], LxRun [21], etc.

Application (Programming Language) Level

A traditional machine is one that executes a set of instructions as supported by the ISA. Using this approach, OS and user-level programs all execute on a machine-like application for the machine. Hardware manipulations are dealt with either by special I/O instructions (I/O mapped), or by mapping a chunk of memory to the I/O and then manipulating the memory. So ultimately, it is a block or sequence of instructions that constitute the application.

The idea is to be able to create a VM at the application-level than can behave like a machine to a set of applications, just like any other machine. Then Java Virtual Machine (JVM) came into the picture, in which it has been widely used in many applications. JVM supports a new self-defined set of instructions (Java byte codes for JVM). Such VMs pose a security threat to the system while letting the user play with it by running applications like he/she would on physical machines. Like a normal machine, it has to be able to provide an operating environment to its applications either by hosting a commercial OS, or by coming up with its own environment. Besides JVM, Microsoft .NET CLI [205] and Parrot [27] also belong to this category. Container-based virtualization such as Docker is a similar approach; however, it provides stronger isolation and self-maintained memory and data, which will be discussed in details in Section 2.3.

Comparison and Summary

In Table 2.1, features such as performance, flexibility, ease of implementation, and degree of isolation are presented at a high-level.

A comparative study among presented virtualizations in the second classification is presented in Table 2.2.

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.

Type 1 Hypervisor

Linux KVM [1]. A KVM (kernel-based VM) is a GNU/Linux based project developed for x86 machines. It operates with a loadable kernel module named kvm.ko, which turns the Linux kernel itself into a hypervisor and thus VMs have direct access to the hardware. KVM also contains processor-specific kernel modules such as kvm-intel.ko and kvm-amd.ko. Virtmanager and virsh applications are generally used to manage the VMs created using KVM. Virt-manager provides a GUI, whereas virsh is a command line utility.

A commonly accepted misconception is that KVM is a Type 2 hypervisor that is hosted by the OS, and not a bare metal hypervisor. This is a persistent myth, but the truth is that KVM actually does run directly on x86 hardware. The interface makes it look like KVM is a hosted hypervisor running on the OS, but the VM is running on the bare metal - the host OS provides a launch mechanism for the hypervisor and then engages in a coprocessing relationship with the hypervisor. In a sense, it is taking over part of the machine and sharing it with the Linux kernel.

On x86 hardware, KVM relies on the hardware virtualization instructions. Using these instructions, the hypervisor and each of its guest VMs run directly on the bare metal, and most of the resource translations are performed by the hardware. This fits the traditional definition of a "Type 1," or bare metal hypervisor. KVM also can be packaged as a standalone hypervisor - like VMware ESX.

VMware ESXi [2]. We may think that VMware products are proprietary and not free but that's not always true. VMware's premium hypervisor product, named VMware ESXi, is available for free download. Though it's not open source, some of its components source software is available for download. However, a user can choose to work for 60 days with all advanced features enabled if the free version's serial number is not entered.

Xen [280]. The Xen Project is one of the leading open source virtualization platforms. The Xen hypervisor is licensed under GPLv2 [3]. Like many of its competitors, Xen is also available in a commercial form from Citrix. Oracle VM is another commercial implementation

of Xen. The Xen Project platform supports many cloud platforms such as OpenStack [220], CloudStack [84], etc. The Xen hypervisor provides an efficient and secure feature set for virtualization of X86, IA64, ARM, and other CPU architectures, and has been used to virtualize a wide range of guest OS, including Windows, Linux, Solaris, and various versions of the BSD OS.

Microsoft Hyper-V [202]. Microsoft introduced Hyper-V as a competitor for many other virtualization products. It's available for free download from an evaluation point of view [203]. The free standalone Hyper-V server 2012 has all the features which are integrated in the Hyper-V role in Windows Server 2012 such as shared nothing live migration, fail-over clustering, etc.

Type 2 Hypervisor

Xvisor [8]. Xvisor is a Type 2 monolithic open source hypervisor that aims to provide lightweight, portable, and flexible virtualization solutions. It is supported on X86 and ARM CPU architectures. One major difference is that Xvisor is completely monolithic - so it has one common software for hardware access, CPU virtualization, and guest IO emulation. However, other virtualization technologies such as KVM and Xen are partially based on monolithic and micro-kernels, respectively. Partially monolithic hypervisors such as KVM are an extension of general-purpose monolithic OSs (such as Linux), which provide host hardware access and CPU virtualization in the kernel and guest IO emulation from an application running in the user space (such as QEMU). Micro-kernel hypervisors are usually lightweight micro-kernels providing basic host hardware access and CPU virtualization in the kernel, whereas the rest are dependent upon managing guests (such as Dom0 of Xen).

Oracle VirtualBox [221]. Oracle VirtualBox is a Type 2 hypervisor that can run on Linux, Windows, Macintosh, and Solaris hosts. It is portable as it can run on a large number of 32-bit and 64-bit host OS. It's called a hosted hypervisor as it requires an existing OS to be installed. One good feature of VirtualBox is that VMs can be easily imported and exported using OVF (Open Virtualization Format) [26]. It's even possible to import OVFs that are created by different virtualization software.

VMware Workstation Player [36]. VMware Workstation Player is a Type 2 desktop virtualization application that provides a streamlined user interface for running and evaluating OS and applications in a VM on Windows or Linux machines. Its simple UI makes it the easiest way to deliver a virtual desktop to your employees, contractors, or customers.

Lguest [19]. Lguest is a very lightweight hypervisor built into the Linux kernel. The core of Lguest is the driver module (named lg) available from Linux kernel 2.6.23 and above. Lguest provides para-virtualized solutions for Linux. The lg driver module, during its initialization, allocates a chunk of memory and maps to the kernel's address space and a small hypervisor is loaded into this memory area. It also provides a virtualized I/O subsystem. It does not provide any of the fancy features other hypervisors do; however, it is a good option when you need to develop and test the kernel boot.

LinuX Containers (LXC)/Docker [5]. LinuX Containers (LXC) is an OS-level visualization method for running multiple isolated Linux systems (containers) on a single control host (LXC host). It does not provide a VM, but a virtual environment that has its own CPU, memory, block I/O, network, etc. It makes use of the Linux kernel's cgroups functionality, which provides isolated namespace(s) to run isolated applications. One advantage of containers is that they do not require a full-fledged guest OS like VMs. For container's details, see Section 2.3.

Linux-VServer [6]. Linux-VServer is an OS level virtualization solution. It's a soft partitioning concept technology based on security contexts. It basically creates Virtual Private Servers (VPS) that run simultaneously on a single physical server by sharing hardware resources. Each VPS has its own database account and root password so that it's isolated from other virtual servers.

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 Lightweight Virtualization: Containers

The hypervisor-based virtualization, including emulation, full and parallel virtualization, consumes many resources since the guests have their own OS running, as shown in Table 2.2. What if the guests share the OS to save the guest OS resource consumption? OS level virtualization is a technique, recently gaining popularity, to host more guests on less resources. Docker [201] is one typical example of this type of virtualization. Moreover, some software packages provide containers to host client codes, which is library and application level virtualization, and which is much lighter and much more flexible. We will introduce OSGi [222] as an example of this type of container. We call the OS, library, and application level virtualization as containers. The key characteristic in all of them is that they share the host OS.

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]1 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's features

Docker is an open-source engine that automates the deployment of applications into containers. It was written by the team at Docker, Inc. (formerly dotCloud Inc., an early player in the Platform-as-a-Service (PAAS) market), and released by them under the Apache 2.0 license.

Docker adds an application deployment engine on top of a virtualized container execution environment. It is designed to provide a lightweight and fast environment in which to run your code as well as an efficient workflow to get that code from your laptop to your test environment and then into production. Docker is incredibly simple. Indeed, you can get started with Docker on a minimal host running nothing but a compatible Linux kernel and a Docker binary.
  • Docker is fast. Applications can be Dockerized in minutes. Docker relies on a copy-onwrite model so that making changes to your application is also incredibly fast - only what you want to change gets changed. A user can then create containers running your applications. Most Docker container take less than a second to launch. Removing the overhead of the hypervisor also means containers are highly performant2 and a user can pack more of them into his hosts and make the best possible use of his resources.
  • With Docker, developers care about their applications running inside containers, and Operators care about managing the containers. Docker is designed to enhance consistency by ensuring the environment in which your developers write code matches the environments into which your applications are deployed.
  • Docker aims to reduce the cycle time between code being written, code being tested, deployed, and used. It aims to make applications portable, easy to build, and easy to collaborate on.
Docker client and server

Docker is a client-server application. The Docker client talks to the Docker server or daemon, which, in turn, does all the work. Docker ships with a command line client binary, Docker, as well as an RESTful [86] API. The "docker" command is run in daemon mode, which turns a Linux system into a Docker server that can have containers deployed, launched, and torn down via a remote client. The Docker command is run in daemon mode to control most of the Docker workflow and talk to remote Docker servers. You can run the Docker daemon and client on the same host or connect your local Docker client to a remote daemon running on another host.

Docker image and container

A Docker image is a template or a class that has all necessary files to create a container. The difference between an image and a container is like the difference between a class and an object. A class is a manuscript of what should be there without any physical existence; and an image contains what should be there without any actual access to any resources (e.g., CPU time, memory, and storage). A container is the object and it has physical existence on the host with an IP, exposed ports, and real processes.

A Docker image is a read-only template. For example, an image can contain an Ubuntu OS with Apache and web applications installed. Images are used to create Docker containers. Docker provides a simple way to build new images or update existing images, or a user can download Docker images that other people have already created. Docker images are the build components of the Docker.

A container is the physically existing collection of processes that uses the OS resources to implement a functionality. The Docker engine takes the image, adds a read-write file system on top, and initializes various settings including network ports, container name, identity, and resource limits. A running container has a currently executing process, and a container can be stopped (or exited to use Docker's terminology). An exited container is not the same as an image, as it can be restarted and will retain its settings and any file system changes.

Docker union file system

Union File System (UnionFS) is a file system service for Linux, FreeBSD, and NetBSD, which implements a union mount3 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 readonly 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,4 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 Mobile Device Virtualization

Mobile device virtualization has become one hot research area recently and has been widely used. Bring your own device (BYOD) is one of widely used mobile virtualization solutions. In Chapter 8, we present such a solution on ARM-based mobile devices. (See Appendix D for detailed implementation and testing results.)

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 Network Virtualization

Network virtualization (NV) is defined by the ability to create logical, virtual networks that are decoupled from the underlying network hardware to ensure the network can better integrate with and support increasingly virtual environments. NV can be delivered via hardware into a logical virtual network that is decoupled from and runs independently on top of a physical network. Beyond Layer 2 or 3 (L2 or L3) services like switching and routing, NV can also incorporate virtualized L4-7 services. With virtualization, organizations can take advantage of the efficiencies and agility of software-based compute and storage resources. While networks have been moving towards greater virtualization, it is only recently, with the true decoupling of the control and forwarding planes, as advocated by Software-Defined Networking (SDN) [163] and Network Function Virtualization (NFV) [126], that network virtualization has become more of a focus.

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).


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 Storage Virtualization

When we talk about the storage on the system, we usually categorize storage into two types: the disks and the file system. In a similar way, storage virtualization solutions can be classified into block and file store.

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).


  • 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.


  • 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.
Reprinted with permission from Elsevier/Morgan Kaufmann, Copyright © 2017.

1 A chroot on Unix OS is an operation that changes the apparent root directory for the current running process and its children. A program that is run in such a modified environment cannot name (and therefore normally cannot access) files outside the designated directory tree.
2 Performant is a word that was made up by software developers to describe software that performs well in whatever way you want to define performance.
3 In computer OS, union mounting is a way of combining multiple directories into one that appears to contain their combined contents.
4 Classpath is a parameter in the Java Virtual Machine or the Java compiler that specifies the location of userdefined classes and packages. The parameter may be set either on the command-line, or through an environment variable.

Dr. Dijiang Huang is Associate Professor in the School of Computing Informatics and Decision Systems Engineering at Arizona State University. He is Editor of IEEE's Communications Surveys & Tutorials and Associate Editor of their Journal of Network & Systems Management. Dr. Huang serves on several committees, including IEEE's Internet Technical Committee on Cloud Communications, Smart Grid Communications Committee, and Cloud Communications & Networking Ad Hoc Committee. He has a Ph.D. in Telecommunications and Computer Networking, an M.S. in Computer Science, and B.E. in Telecommunications. Dr. Huang is the author of more than 120 articles published in 28 journals.

Dr. Huijun Wu is currently an engineer at Twitter contributing to the Heron project that is a real-time, distributed, fault-tolerant stream processing engine. He received his Ph.D. from Arizona State University in 2016 with a thesis on "Mobile Cloud Application Framework and Offloading Strategies." His research interests are in mobile cloud computing, computation offloading strategies, service oriented architecture and distributed systems. Dr. Wu received a M.S. (2009) and a B.S. (2007) from Huazhong University of Science and Technology. He previously worked in Alcatel-Lucent Shanghai Bell from 2009 to 2011.

Related Keywords:movie,

Source:Digital Media Online. All Rights Reserved

Our Privacy Policy --- @ Copyright, 2015 Digital Media Online, All Rights Reserved