1

UNIT – 2

Virtual Machines and Virtualization of Clusters and Data Centers

Implementation Levels of Virtualization

Virtualization is a concept by which several VMs are multiplexed into the same hardware machine.
The purpose of a VM is to enhance resource sharing by many users and improve computer performance in
terms of resource utilization and application flexibility. Hardware resources (CPU, memory, I/O devices
etc.) or software resources (OS and apps) can be virtualized at various layers of functionality.

The main idea is to separate hardware from software to obtain greater efficiency from the system.
Ex: Users can gain access to more memory by this concept of VMs. With sufficient storage, any computer
platform can be installed in another host computer, even if processors’ usage and operating systems are
different.

Levels of Virtualization Implementation:

A traditional computer system runs with a host OS specially adjusted for its hardware architecture.
This is shown in Figure 3.1a [1].
After virtualization, different user apps managed by their own OS (i.e., guest OS) can run on the
same hardware, independent of the host OS. This is often done by adding a virtualization layer as shown
in Figure 3.1b [2].
This virtualization layer is called VM Monitor or hypervisor. The Virtual Machines can be seen in
the upper boxes where apps run on their own guest OS over a virtualized CPU, memory and I/O devices.
The main function of the software layer for virtualization is to virtualize the physical hardware of a host
machine into virtual resources to be saved by the VMs. The virtualization software creates the abstract of
VMs by introducing a virtualization layer at various levels of a computer.
General virtualization layers include the instruction set architecture (ISA) level, hardware level, OS
level, library support level, and app level.
 2

Instruction Set Architecture Level: At the ISA level, virtualization is performed by emulation (imitate)
of the given ISA by the ISA of the host machine. Ex: MIPS binarycode can run on an x86-based host
machine with the help of ISA simulation. Instructionemulation leads to virtual ISAs created on any
hardware machine.
A dynamic binary translation can be used where it translates blocks of dynamic source instructions
to target instructions. The basic blocks can also be extended to program traces or super blocks to increase
translation efficiency. This emulation requires binary translation and optimization. Hence, a Virtual-ISA
requiresa processor specific translation layer to the compiler.
Hardware Abstraction Level: Hardware level virtualization is performed on the bare hardware. This
approach generates a virtual hardware environment and processes the hardware in a virtual manner. The
idea is to virtualize the resources of a computer by utilizing them concurrently. Ex: IBM Xen hypervisor
(VMM) runs Linux or other guestOS applications.
OS Level: This refers to an abstraction layer between the OS and the user apps. The OS level
virtualization creates isolated containers on a single physical server and OS instances to utilize software
and hardware in data centers. The containers behave like real servers. OS level virtualization is used in
creating virtual hosting environments to allocate hardware resources among a large number of
‘distrusting’ users. It can also be used to indirectly merge server hardware by moving resources on
different hosts into different containers or VMs on one server.
Library Support Level: Most applications use APIs exported by user-level libraries rather than lengthy
system calls by the OS. Virtualization with library interfaces is possible by controlling the communication
link between apps and the rest of the systemthrough API hooks.
User-App Level: An app level virtualization brings out a real VM; this process is also known as process
level virtualization. Generally HLL VMs are used where virtualization layer is an app above the OS; it can
run programs written and compiled to an abstract machine definition. Ex: JVM and .NET CLR (Common
Language Runtime).
 3

VMM Design Requirement and Providers:

Hardware-level virtualization inserts a layer between real hardware and traditional OS. This layer
(VMM/hypervisor) manages the hardware resources of the computer effectively. By the usage of VMM,
different traditional operating systems can be used with the same set of hardware simultaneously.
Requirements for a VMM:
(a) For programs, a VMM should provide an identical environment, same as the original
machine.
(b) Programs running in this environment should show only minor decreases in speed.
(c) A VMM should be in complete control of the system resources. Any program run under a
VMM should exhibit a function identical to that which it runs on the original machine
directly.

The hardware resource requirements (like memory) of each VM are reduced, but the total sum of
them is greater that of the real machine is installed. This is needed because of any other VMs that are
concurrently running on the same hardware. A VMM should demonstrate efficiency in using the VMs. To
guarantee the efficiency of a VMM, a statistically dominant subset of the virtual processor’s instructions
needs to be executed directly by the real processor with no intervention by the VMM. A comparison can
be seen in Table 3.2 .

Complete control of these resources by a VMM includes the following aspects: (1) The VMM is
responsible for allocating hardware resources for programs; (2) it is not possible for a program to access
any resource not explicitly allocated to it; and (3) it is possible under certain circumstances for a VMM to
regain control of resources already allocated. Not all processors satisfy these requirements for a VMM.
 4

Virtualization Support at the OS Level:

The challenges of CC are: The first is the ability to use a variable number of physical machines
and VM instances depending on the needs of a problem. For example, a task may need only a single CPU
during some phases of execution but may need hundreds of CPUs at other times. The second challenge
concerns the slow operation of instantiating new VMs. Currently, new VMs originate either as fresh boots
or as replicates of a template VM, unaware of the current application state. Therefore, to better support
cloud computing, a large amount of research and development should be done.
Why OS Level Virtualization
Disadvantages of hardware level virtualization:
(a) It is slow to initiate a hardware level VM since each VM creates its own image from
the beginning.
(b) Redundancy content is high in these VMs.
(c) Slow performance and low density
(d) Hardware modifications maybe needed

To provide a solution to all these problems, OS level virtualization is needed. It inserts a

virtualization layer inside the OS to partition the physical resources of a system. It enables multiple
isolated VMs within a single OS kernel. This kind of VM is called a Virtual Execution
Environment (VE) or Virtual Private System or simply a container. From the user’s point of view,
a VE/container has its own set of processes, file system, user accounts, network interfaces (with IP
addresses), routing tables, firewalls and other personal settings. . Although VEs can be customized
for different people, they share the same operating system kernel. Therefore, OS-level virtualization
is also called single-OS image virtualization
 5

Advantages of OS Extensions:
(a) VMs at the OS level have minimal start-up shutdown costs, low resource requirements and
high scalability.
(b) For an OS level VM, the VM and its host environment can synchronize state changes
These can be achieved through two mechanisms of OS level virtualization:

(a) All OS level VMs on the same physical machine share a single OS kernel
(b) The virtualization layer can be designed in way that allows processes in VMs can access as
many resources as possible from the host machine, but can never modify them.

Disadvantages of OS Extension: The main disadvantage of OS extensions is that all VMs at OS level on a
single container must have the same kind of guest OS. Though different OS level VMs may have different
OS distributions (Win XP, 7, 10), they must be related to the same OS family (Win). A Windows
distribution can’t run on a Linux based container. To implement this OS level virtualization, isolated
execution environments (VMs) should be created based on a single OS kernel

Middleware Support for Virtualization:

This is the other name for Library-level Virtualization and is also known as user-level
Application Binary Interface or API emulation. This type of virtualization can create execution
environments for running alien (new/unknown) programs on a platform rather than creating a VM to run
the entire OS. The key functions performed here are API call interception and remapping.
Example: The vCUDA for Virtualization of General-Purpose GPUs
CUDA is a programming model and library for general-purpose GPUs. vCUDA virtualizes the CUDA
library and can be installed on guest OSes. When CUDA applications run on a guest OS and issue a call to
the CUDA API, vCUDA intercepts the call and redirects it to the CUDA API running on the host OS.
Figure 3.4 shows the basic concept of the vCUDA architecture.

The vCUDA employs a client-server model to implement CUDA virtualization. It consists of

three user space components: the vCUDA library, a virtual GPU in the guest OS (which acts as a client),
and the vCUDA stub in the host OS (which acts as a server).
The vCUDA library resides in the guest OS as a substitute for the standard CUDA library. It is
responsible for intercepting and redirecting API calls from the client to the stub. Besides these tasks,
vCUDA also creates vGPUs and manages them.
The functionality of a vGPU is threefold: It abstracts the GPU structure and gives applications
a uniform view of the underlying hardware; when a CUDA application in the guest OS allocates a
device’s memory the vGPU can return a local virtual address to the application and notify the remote stub
to allocate the real device memory, and the vGPU is responsible for storing the CUDA API flow. The
vCUDA stub receives and interprets remote requests and creates a corresponding execution context for the
API calls from the guest OS, then returns the results to the guest OS. The vCUDA stub also manages
actual physical resource allocation.
 6

Virtualization Structures/Tools and Mechanisms:

VM architectures: Before virtualization, the OS manages the hardware. After virtualization, a
virtualization layer is inserted between the hardware and the OS. Here, the virtualization layer is
responsible for converting parts of real hardware into virtual hardware. Different operating systems like
Windows and Linux can run simultaneously on the same machine in this manner. Depending on the
position of the virtualization layer, several classes of VM architectures can be framed out: Hypervisor
Architecture, para-virtualization and host-based virtualization.

Hypervisor and Xen Architecture: The hypervisor (VMM) supports hardware level virtualization on
bare metal devices like CPU, memory, disk and network interfaces. The hypervisor software exists
between the hardware and its OS (platform). The hypervisor provides hypercalls for the guest operating
systems and applications. Depending on the functionality, a hypervisor can assume micro-kernel
architecture like MS Hyper-V or monolithic hypervisor architecture like the VMware ESX for server
virtualization.
Xen Architecture: It is an open source hypervisor program developed by Cambridge University.
Xen is a micro-kernel hypervisor, whose policy is implemented by Domain 0.

Xen doesn’t include any device drivers; it provides a mechanism by which a guest-OS can have
direct access to the physical devices. The size of Xen is kept small, and provides a virtual environment
between the hardware and the OS. Commercial Xen hypervisors are provided by Citrix, Huawei and
Oracle.
The core components of Xen are the hypervisor, kernel and applications. Many guest operating
systems can run on the top of the hypervisor; but it should be noted that one of these guest OS controls the
others. This guest OS with the control ability is called Domain 0 – the others are called Domain U.
Domain 0 is first loaded when the system boots and can access the hardware directly and manage devices
by allocating the hardware resources for the guest domains (Domain U).
If a user has access to Domain 0 (VMM), he can create, copy, save, modify or share files and
resources of all the VMs. This is a huge advantage for the user but concentrating all the resources in
Domain 0 can also become a privilege for a hacker. If Domain 0 is hacked, through it, a hacker can control
all the VMs and through them, the total host system or systems. Security problems are to be dealt with in a
careful manner before handing over Xen to the user.
 7

Binary Translation with Full Virtualization: Hardware virtualization can be categorised into two
categories: full virtualization and host-based virtualization.

Full Virtualization doesn’t need to modify the host OS; it relies upon binary translation to trap and to
virtualize certain sensitive instructions. Normal instructions can run directly on the host OS. This is done
to increase the performance overhead – normal instructions are carried out in the normal manner, but the
difficult and precise executions are first discovered using a trap and executed in a virtual manner. This is
done to improve the security of the system and also to increase the performance.

Binary Translation of Guest OS Requests Using a VMM:

This approach is mainly used by VMware and others. The VMware puts the VMM at Ring 0 and the
guest OS at Ring 1. The VMM scans the instructions to identify complex and privileged instructions and
trap them into the VMM, which emulates the behaviour of these instructions. Binary translation is the
method used for emulation. Note that full virtualization combines both binary translation and direct
execution. The guest OS is totally decoupled from the hardware and run virtually (like an emulator).
Full virtualization is ideal since it involves binary translation and is time consuming. Binary
translation also is cost consuming but it increases the system performance. (Same as 90% of the host).

Host-based virtualization: In a host-based virtualization system both host and guest OS are used and a
virtualization layer is built between them. The host OS is still responsible for managing the hardware
resources. Dedicated apps might run on the VMs and some others can run on the host OS directly. By
using this methodology, the user can install the VM architecture without modifying the host OS. The
virtualization software can rely upon the host OS to provide device drivers and other low level services.
Hence the installation and maintenance of the VM becomes easier.

Para-Virtualization with Compiler Support: Para-Virtualization modifies the guest operating systems;
a para-virtualized VM provides special APIs which take up user apps needing those changes. Para-
virtualization tries to reduce the virtualization burden/extra- work to improve the performance – this is
done by modifying only the guest OS kernel.
 8

In a typical para-virtualization architecture, which considers an x86 processor, a virtualization layer

is inserted between h/w and OS. According to the x86 ‘ring definition’ the virtualization layer should also
be installed at Ring 0. In Figure 3.8, we can notice that para- virtualization replaces instructions that cannot
be virtualized with hypercalls (placing a trap) that communicate directly with the VMM. Notice that if a
guest OS kernel is modified for virtualization, it can’t run the hardware directly – that should be done
through the virtualizationlayer.

Disadvantages of Para-Virtualization: Its compatibility (suitability) and portability can be in doubt

because it has to support both the modified guest OS and the host OS as per requirements. Also, the
maintenance cost of para-virtualization is high since it may require deep kernel modifications. Finally, the
performance advantage of para-virtualization is not stable – it varies as per the workload.

But compared with full virtualization, para-virtualization is more easy and practical since binary
translation is not much considered. Many products utiliza para-virtualization to overcome the less speed of
binary translation. Ex: Xen, KVM, VMware ESX.

Virtualization of CPU, Memory and I/O Devices

H/W Support for Virtualization: Modern operating systems and processors permit multiple processes to
run simultaneously. A protection mechanism should exist in the processor so that all instructions from
different processes will not access the hardware directly – this will lead to a system crash.
All processors should have at least two modes – user and supervisor modes to control the access to
the hardware directly. Instructions running in the supervisor mode are called privileged instructions and
the others are unprivileged. Ex: VMware Workstation

CPU Virtualization: A VM is a duplicate of an existing system; majority of instructions are executed by

the host processor. Unprivileged instructions run on the host machine directly; other instructions are to be
handled carefully. These critical instructions are of three types: privileged, control-sensitive and
behaviour-sensitive.
Privileged=> Executed in a special mode and are trapped if not done so.
Control-Sensitive=> Attempt to change the configuration of the used resources
Behaviour-Sensitive=> They have different behaviours in different situations (high load or
storage or capacity)
 9

A CPU is virtualized only if it supports the VM in the CPU’s user mode while the VMM runs in a
supervisor’s mode. When the privileged instructions are executed, they are trapped in the VMM. In
this case, the VMM acts as a mediator between the hardware resources and different VMs so that
correctness and stability of the system are not disturbed. It should be noted that not all CPU
architectures support virtualization.
Hardware Assisted CPU virtualization: Since full virtualization or para- virtualization is
complicated, this new methodology tries to simplify the situation. Intel and AMD add an additional
mode called privilege mode level to the x86 processors. The OS can still run at Ring 0 and
hypervisor at Ring 1. Note that all privileged instructions are trapped at the hypervisor. Hence, no
modifications are required in the VMs at OS level.

VMCS=> VM Control System

VMX=> A virtual router

Memory Virtualization: In the traditional methodology, the OS maintains mappings between virtual
memory to machine memory (MM) using page tables, which is a one-stage mapping from virtual memory
to MM. In a virtual execution environment, virtual memory virtualization involves sharing the physical
system memory in RAM and dynamically allocating it to the physical memory of the VMs.
Stages:
 Virtual memory to physical memory
 Physical memory to machine memory.

Other Points: MMU should be supported, guest OS controls to monitor mapping of virtual
addresses to physical memory address of the VMs. All this is depicted in Figure 3.12 .
 10

VA-Virtual Address; PA-Physical Address; MA-Machine Address

Each page table of a guest OS has a page table allocated for it in the VMM. The page table in the
VMM which handles all these is called a shadow page table. As it can be seen all this process is nested
and inter-connected at different levels through the concerned address. If any change occurs in the virtual
memory page table or TLB, the shadow page table in the VMM is updated accordingly.

I/O Virtualization: This involves managing of the routing of I/O requests between virtual devices and
shared physical hardware. The there are three ways to implement this are full device emulation, para-
virtualization and direct I/O.
 Full Device Emulation: This process emulates well-known and real-world devices. All the
functions of a device or bus infrastructure such as device enumeration, identification, interrupts
etc. are replicated in the software, which itself is located in the VMM and acts as a virtual
device. The I/O requests are trapped in the VMM accordingly. The emulation approach can be
seen in Figure 3.14.

 Para- virtualization: This method of I/O virtualization is taken up since software emulation
runs slower than the hardware it emulates. In para- virtualization, the frontend driver runs in
Domain-U; it manages the requests of the guest OS. The backend driver runs in Domain-0 and
is responsible for managing the real I/O devices. This methodology (para) gives more
performance but has a higher CPU overhead.
 Direct I/O virtualization: This lets the VM access devices directly; achieves high
performance with lower costs. Currently, it is used only for the mainframes.

Ex: VMware Workstation for I/O VZ: NIC=> Network Interface Controller
 11

Virtualization in Multi-Core Processors:

Virtualizing a multi-core processor is more complicated than that of a uni-core processor.
Multi-core processors have high performance byintegrating multiple cores in a chip, but their virtualization
poses a new challenge. The main difficulties are that apps must be utilized in a parallelized way to use all
the cores and this task must be accomplished by software, which is a much higher problem. To reach these
goals, new programming models, algorithms, languages and libraries are neededto increase the parallelism.

Physical versus Virtual Processor Cores: A multi-core virtualization method was proposed to allow
hardware designers to obtain an abstraction of the lowest level details of all the cores. It is located under
the ISA (Instruction Set Architecture) and is unmodified by the OS or hypervisor.

Virtual Hierarchy: A virtual hierarchy is a cache hierarchy that can adapt to fit the workloads. First level
in the hierarchy locates data blocks close to the cores to increase the access speed; it then establishes a
shared-cache domain, establishes a point of coherence, thus increasing communication speed between the
levels.
 12

Space sharing is applied to assign three workloads to three clusters of virtual cores: VM0 and VM3
for DB workload, VM1 and VM2 for web server workload, and VM4-VM7 for middleware workload.
Basic assumption here is that a workload runs in its own VM. But in a single OS, space sharing applies
equally. To encounter this problem, Marty and Hill suggested a two-level virtual coherence and caching
hierarchy. This can be seen in Figure 3.17(b). Each VM operates in its own virtual cluster in the first
level which minimizes both access time and performance interference. The second level maintains a globally
shared memory.

Virtual Clusters and Resource Management

A physical cluster is a collection of physical servers that are interconnected. The issues that are to be dealt
with here are: live migration of VMs, memory and file migrations and dynamic deployment of virtual
clusters. When a general VM is initialized, the administrator has to manually write configuration
information; this increases his workload, particularly when more and more VMs join the clusters. As a
solution to this, a service is needed that takes care of the configuration information (capacity, speed etc.) of
the VMs. The best example is Amazon’s Elastic Compute Cloud (EC2), which provides elastic computing
power in a cloud.
Physical versus Virtual Clusters: Virtual Clusters are built with VMs installed at one or more physical
clusters. The VMs in a virtual cluster are interconnected by a virtual network across several physical
networks. The concept can be observed in Figure 3.18 [1]. The provisioning of VMs to a virtual cluster
is done dynamically to have the following properties:
 The virtual cluster nodes can be either physical or virtual (VMs) with different operating
systems.
 A VM runs with a guest OS that manages the resources in the physical machine.
 The purpose of using VMs is to consolidate multiple functionalities on the same server.
 VMs can be replicated in multiple servers to promote parallelism, fault tolerance and
disaster discovery.
 The no. of nodes in a virtual cluster can grow or shrink dynamically.
 The failure of some physical nodes will slow the work but the failure of VMs will cause no
harm (fault tolerance is high).
 13

Virtual cluster based on app partitioning

The different colors represent nodes in different virtual clusters. The storage images (SSI) from
different VMs from different clusters is the most important concept here. Software packages can be pre-
installed as templates and the users can build their own software stacks. Note that the boundary of the
virtual cluster might change since VM nodes are added, removed, or migrateddynamically.
Fast Deployment and Effective Scheduling: The concerned system should be able to
 Construct and distribute software stacks (OS, libraries, apps) to a physical node inside
the cluster as fast as possible
 Quickly switch runtime environments from one virtual cluster to another.
High Performance Virtual Storage: A template must be prepared for the VM construction and usage
and distributed to the physical hosts. Users should be identified by their profiles that are stored in data
blocks. All these methods increase the performance in virtual storage. Ex: Dropbox

Steps to deploy (arrange/install) a group of VMs onto a target cluster:

 Preparing the disk image (SSI)
 Configuring the virtual machines
 Choosing the destination nodes
 Executing the VM deployment commands at every host
 14

Live VM Migration Steps:

Normally in a cluster built with mixed modes of host and guest systems, the procedure is to run
everything on the physical machine. When a VM fails, it can be replaced by another VM on a different
node, as long as they both run the same guest OS. This is called a failover of a physical system to a VM.
Compared to a physical-physical failover, this methodology has more flexibility. It also has a drawback–
a VM must stop working if its host node fails. This can be lessened by migrating from one node to
another for a similar VM. The live migration process is depicted in Figure 3.20 .

A VM can be in one of the following states:

(a) Inactive State: This is defined by the VZ platform, under which the VM is not enabled.
(b) Active State: This refers to a VM that has been instantiated at the VZ platform to perform
a task.
(c) Paused State: A VM has been instantiated but disabled temporarily to process a task or
is in a waiting state itself.
(d) Suspended State: A VM enters this state if its machine file and virtual resources are
stored back to the disk.

Live Migration Steps: This consists of 6 steps.

(a) Steps 0 and 1: Start migration automatically and checkout load balances and server
consolidation.
(b) Step 2: Transfer memory (transfer the memory data + recopy any data that is changed
during the process). This goes on iteratively till changed memory is small enough to be
handled directly.
 15

(c) Step 3: Suspend the VM and copy the last portion of the data.
(d) Steps 4 and 5: Commit and activate the new host. Here, all the data is recovered, and the
VM is started from exactly the place where it was suspended, but on the new host.

Migration of Memory, Files, and Network Resources

Memory Migration: This is done between the physical host and any other physical/virtual machine. The
techniques used here depend upon the guest OS. MM can be in a range of megabytes to gigabytes. The
Internet Suspend-Resume (ISR) technique exploits temporal locality since the memory states are may
have overlaps in the suspended/resumed instances of a VM. Temporal locality (TL) refers to the fact that
the memory states differ only by the amount of work done since a VM was last suspended.
To utilize the TL, each file is represented as a tree of small sub-files. A copy of this tree exists in both the
running and suspended instances of the VM. The advantage here is usage of tree representation of a file
and caching ensures that the changed files are only utilized for transmission.

File System Migration: To support VM migration from one cluster to another, a consistent and location-
dependent view of the file system is available on all hosts. Each VM is provided with its own virtual disk to
which the file system is mapped to. The contents of the VM can be transmitted across the cluster by inter-
connections (mapping) between the hosts. But migration of an entire host (if required) is not advisable due
to cost and security problems. We can also provide a global file system across all host machines where a
VM can be located. This methodology removes the need of copying files from one machine to another – all
files on all machines can be accessed through network.
It should be noted here that the actual files are not mapped or copied. The VMM accesses only the
local file system of a machine and the original/modified files are stored at their respective systems only.
This decoupling improves security and performance but increases the overhead of the VMM – every file
has to be stored in virtual disks in its local files.
Network Migration: A migrating should maintain open network connections. It should not depend upon
forwarding mechanisms or mobile mechanisms. Each VM should be assigned a unique IP or MAC (Media
Access Control) addresses which is different from that of the host machine. The mapping of the IP and
MAC addresses to their respective VMs is done by the VMM. If the destination of the VM is also on the
same LAN, special messages are sent using MAC address that the IP address of the VM has moved to a
new location. If the destination is on another network, the migrating OS can keep its original Ethernet
MAC address and depend on the network switch to detect its move to a new port.
There are two approaches in live migration: pre copy and post copy.
(a) In pre copy, which is manly used in live migration, all memory pages are first transferred;
it then copies the modified pages in the last round iteratively. Here, performance
‘degradation’ will occur because migration will be encountering dirty pages all around
in the network before getting to the right destination. The iterations could also increase,
causing another problem. To encounter these problems, check-pointing/recovery process
is used at different positions to take care of the above problems and increase the
performance.
(b) In post-copy, all memory pages are transferred only once during the migration process.
The threshold time allocated for migration is reduced. But the downtime is higher than
that in pre-copy.
 16

Virtualization for Data Centre Automation

Data Centres have been built and automated recently by different companies like Google, MS,
IBM, Apple etc. By utilizing the data centres and the data in the same, virtualization is moving towards
mobility, reduced maintenance time, and increasing the number of virtual clients. Other factors that
influence the deployment and usage of data centres are high availability (HA), backup services, and
workload balancing.

Server Consolidation in Data Centres: In data centers, heterogeneous workloads may run at different
times. The two types here are
(a) Chatty (Interactive) Workloads: These types may reach the peak at a particular time and
may be silent at some other time. Ex: WhatsApp in the evening and the same at midday.
(b) Non-Interactive Workloads: These don’t require any users’ efforts to make progress after
they have been submitted. Ex: HPC
The data center should be able to handle the workload with satisfactory performance both at the
peak and normal levels.
Server consolidation: This improves the server utility ratio of hardware devices by reducing the number
of physical servers. There exist two types of server consolidation:
(a) Centralized and Physical Consolidation (b) VZ based server consolidation.
 virtualization based Consolidation increases hardware utilization
 It enables more agile provisioning of the available resources
 The total cost of owning and using data center is reduced (low maintenance, low cooling,
low cabling etc.)
 It enables availability and business continuity – the crash of a guest OS has no effect upon
a host OS.
To automate (VZ) data centers one must consider several factors like resource scheduling, power
management, performance of analytical models and so on. This improves the utilization in data centers
and gives high performance. Scheduling and reallocation can be done at different levels at VM level,
server level and data center level, but generally any one (or two) level is used at a time.

The schemes that can be considered are:

(a) Dynamic CPU allocation: This is based on VM utilization and app level QoS (Quality
of Service) metrics. The CPU should adjust automatically according to the demands and
workloads to deliver the best performance possible.
(b) Another scheme uses two-level resource management system to handle the complexity of
the requests and allocations. The resources are allocated automatically and autonomously
to bring down the workload on each server of a data center.

Virtual Storage Management: virtualization is mainly lagging behind the modernization of data centers
and is the bottleneck of VM deployment. The CPUs are rarely updates, the chips are not replaced and the
host/guest operating systems are not adjusted as per the demands of situation. Also, the storage
methodologies used by the VMs are not as fast as they are expected to be. Thousands of such VMs may
flood the data center and their lakhs of images (SSI) may lead to data center collapse. Research has been
conducted for this purpose to bring out an efficient storage and reduce the size of images by storing parts
of them at different locations. The solution here is Content Addressable Storage (CAS).
 17

Ex: Parallax system architecture (A distributed storage system). This can be viewed at Figure 3.26.Note
that Parallax itself runs as a user-level application in the VM storage, providing Virtual Disk Images
(VDIs). A VDI can access in a transparent manner from any host machine in the Parallax cluster. It is a
core abstraction of the storage methodology used by Parallax.

Cloud OS for virtualization Data Centers:

VI => Virtual Infrastructure managers

EC2 => Amazon Elastic Compute Cloud
WS => Web Service
CLI => Command Line Interface
 18

WSRF => Web Services Resource Framework

KVM => Kernel-based VM
VMFS => VM File System
HA => High Availability
Trust Management in VZ Data Centers:
As a recollect, a VMM (hypervisor) is a layer between the host OS and the hardware to create one or
more VMs on a single platform. A VM encapsulates the guest OS and its current state and can transport it
through the network as a SSI. At this juncture, in the network transportation, any intruders may get into the
image or the concerned hypervisor itself and pose danger to both the image and the host system. Ex: A subtle
problem lies in reusing a random number for cryptography.

VM-based Intrusion Detection: Intrusions are unauthorized access to a computer from other network
users. An intrusion detection system (IDS), which is built on the host OS can be divided into two types:
host-based IDS (HIDS) and a network-based IDS (NIDS). Virtualization based IDS can isolate each VM
on the VMM and work upon the concerned systems without having contacts with the other. Any problem
with a VM will not pose problems for other VMs. Also, a VMM audits the hardware allocation and usage
for the VMs regularly so as to notice any abnormal changes.

The above figure proposes the concept of granting IDS runs only on a highly-privileged VM. A policy
framework can monitor the events in different guest operating systems of different VMs by using an OS
interface library to determine which grant is secure and which is not. Systems also may use access ‘logs’
to analyze which is an intrusion and which is secure. The IDS log service is based on the OS kernel and
the UNIX kernel is hard to break; so even if a host machine is taken over by the hackers, the IDS log
book remains unaffected.