A SURVEY ON VIRTUALIZATION TECHNOLOGY
IN CLOUD COMPUTING
Miss.Pratima D.Nerkar
1, Prof.Suresh B.Rathod
2 1,2Department of Computer Engineering, Sinhagad Academy of Engineering, Pune University, (India)
ABSTRACT
Cloud computing is the latest distributed computing paradigm and it offers tremendous opportunities to solve large-scale scientific problems. Virtualization has been an essential technique for Cloud resources and data centers not only to decrease operating costs, but also to improve the system reliability. Cloud computing -a favourite computing system today.It’s a new paradigm which delivers computing services to users as utilities in a pay-as-you-go manner. It’s not a new technology; it’s just a way of using old services effectively. To solve an emerging real time service management problem in cloud computing, live virtual machine (VM) migration is needed. Live migration of virtual machine is a major factor in cloud computing.
Keywords: Cloud Computing, Virtualization, Live Virtual Machine Migration, Real Time Service.
I INTRODUCTION
Expansion of internetworking coupled with Service Oriented Architecture gave birth to new concepts like Cloud Computing which cater exponentially increasing demand of data generation, storage, integration and communication. The key concept operating at lower level of cloud computing stack is Virtualization. ―Virtualization, in computing, is the creation of a virtual (rather than actual) version of something, such as a hardware platform, operating system, a storage device or network resources‖ [1]. Basically it is a technique that divides a physical computer into several isolated machines known as virtual machines (VM). Multiple virtual machines can run on a host computer, each possessing its own operating system and applications. This gives an illusion to the processes running on virtual machines as if they are using dedicated hardware resources, but in reality they are sharing the physical hardware of the host machine. The task of seamlessly isolating VMs and managing timely allocation of resources is done by an additional software component called Hypervisor or Virtual Machine Monitor (VMM).Virtualization can be used to club together applications running on different servers, on a single host under different virtual machines (termed as sever virtualization)[[2]. For the success of server virtualization Hypervisor or Virtual Machine Monitor, should ensure CPU, memory, network and IO virtualization (different virtual machines get a feeling of having these resources dedicated to them but in reality they are shared with time
multiplexing). This reduces infrastructure required and eventually operational and maintenance cost[3][4]. In addition to cost effectiveness virtualization brings many benefits like high availability, scalability, less power consumption etc.
II VIRTUALIZATION
Virtualization was first developed in 1960’s by IBM Corporation, originally to partition large mainframe computers into several logical instances and to run on single physical mainframe hardware as the host. This feature was invented because maintaining the larger mainframe computers became cumbersome. This capability of partitioning allows multiple processes and applications to run at the same time, thus increasing the efficiency of the environment and decreasing the maintenance overhead. Due to the benefits it offers virtualization has become fundamental building block for today’s computing. As desktop and server processing capacity has consistently increased year after year, virtualization has proved to be a powerful technology to simplify software development and testing, to enable server consolidation, and to enhance data centre agility and business continuity. As it turns out, fully abstracting the operating system and applications from the hardware and encapsulating them into portable virtual machines has enabled virtual infrastructure features which are not possible with hardware alone.
Figure 1: Components of Server Virtualization
As mentioned in Fig.1 the basic components of virtualized environment areHost Machine Hardware – This includes normal physical computer system hardware like CPU, memory, network interface, data buses, secondary storage etc.
Host Machine Operating System (Base OS) – This is applicable for Type 2 hypervisors, where hypervisor leverages certain functionalities of OS like memory management, resource allocation scheduling, time sharing and provides only add-on functionalities like maintaining VM state, virtual to physical memory mapping, requesting resources for VM etc.
Hypervisor – It is abstraction layer between bare metal hardware of host machine and virtual machine. This software layer is in charge of communication between guest OS (which doesn’t run at highest privilege level as required by
CPU) with the underlying hardware.
Guest OS – Guest OS is any normal operating system which is installed on virtual machine instead of physical host. It can be unmodified OS (as in case of Full Virtualization) or modified one (as in case of Para-Virtualization). Guest Application – It is normal application developed providing certain business functionality and deployed on virtual machine OS.
2.1 Virtual Machine Monitor (VMM) / Hypervisor
The software component called Hypervisor allows multiple operating systems to share a single hardware host. It is an abstraction layer between host machine hardware and virtual machine OS. (Guest OS). Each guest OS appears to have the host's processor, memory, and other resources all to itself. However, the hypervisor is actually controlling the host processor and resources, allocating what are needed to each operating system in turn and making sure that the guest operating systems (called virtual machines) cannot disrupt each other.
There are two types of hypervisors
1. Type 1 (or native, bare metal) hypervisors run directly on the host's hardware to control the hardware and to manage guest operating systems. A guest operating system thus runs on another level above the hypervisor as shown in Fig. 2 Examples are Oracle VM Server for SPARC, the Citrix Xen Server, KVM, VMware ESX/ESXi, and Microsoft Hyper-V hypervisor.
F
Fiigguurree22::TTyyppee11 FFiigguurree33::TTyyppee22
2. Type 2 (or hosted) hypervisors run within a conventional operating system environment. With the hypervisor layer as a distinct second software level, guest operating systems run at the third level above the hardware. as shown in Fig. 3 .Examples are VMware Workstation and VirtualBox.
2.1.1 Hardware Support
To implement a Virtual Machine Monitor on a x86 architecture, hardware assistance is needed. The privilege levels implemented by the CPU to restrict tasks that processes can do, are one aspect. Another one is the memory management that is emulated by the VMM which tends to be inefficient. Hardware support could lead to an increased performance of the virtual machines by supporting a VMM.
2.1.2 Privilege levels
drivers or access the hardware directly, for example. To restrict all running applications to only a subset of the resources, the OS and the CPU conspire using privilege levels as shown in Fig.4 A x86 CPU runs in a specific privileged level at any given time. Figure 3 shows these levels as rings. Ring 0 is the most privileged and ring 3 is the least privileged. The resources that are protected through the rings are: memory, I/O ports and CPU instructions. The operating system typically runs in ring 0. It needs the most privileged level to do resource management and provide access to the hardware. All the applications run in ring 3. Ring 1 and 2 are widely unused. From a OSs point of view ring 0 is called kernel-mode and ring 3 user-mode. The VMM needs to access the memory, CPU and I/O devices of the host. Since only code running in ring 0 is allowed to perform these operations, it needs to run in the most privileged ring, next to the kernel. An operating system installed in a VM also expects to access all the resources and in order of that running in ring 0 like the VMM does. Due to the fact that only one kernel can run in ring 0 at the same time, the guest OSs have to run in another ring with less privileges or have to be modified to run in user-mode. Intel and AMD realized that this is a major challenge of virtualization on the x86 architecture. So they introduced Intel VT and AMD SVM as an extension of the IA-32 instruction set for better support of virtualization. These extensions allow the VMM to run a guest OS that expects to run in kernel-mode, in a lower privileged ring.
Figure 4: CPU privilege levels 2.1.3 Memory Management
In order to run several VMs on top of a server, a multiple of the amount of memory that is attached to a common server is needed. Since each VM runs an entire operating system and applications on that, it is recommended to assign as much memory to a VM as a comparable physical machine would have. The VMM splits the physical memory of the host into contiguous blocks of fixed length and maps it into the address space provided to a VM. Most modern systems are using virtual memory management. This technique al- lows to provide the previously mentioned contiguous blocks of memory to a VM, although it is fragmented all over the physical memory or even partially stored on the hard disk. In this case it has to be copied back to memory by the virtual memory management first, when accessed. Since a VM is unaware of the physical address of its address space, it can’t figure out whether a part of its virtual memory has to be copied or not. To achieve that, the VMM holds a so called shadow page table that stores the physical location of the virtual memory of all VMs. Thus, any time a VM writes to its memory, the operation has to be intercepted to keep the shadow pages up to date. When a swapped address is accessed the VMM first uses the virtual memory management to restore it.With the introduction of Intel’s Extended Paging Tables (EPT) and AMD’s Nested Paging Tables (NPT) a VMM can use hardware support for the translation be- tween
virtual and physical memory. This reduces the overhead of holding shadow pages and increases the performance of a VMM.
2.2 Types of virtualization
There are three types of hardware virtualization
Full virtualization - In full virtualization almost complete simulation of the actual hardware is done by hypervisor, which typically consists of a guest operating system, to run unmodified. One of the ways deployed to do this is binary in which nonvirtualizable instructions are replaced with new sequences of instructions that have the intended effect on the virtual hardware Ex – VMWare Workstation, VirtualBox
Para virtualization - In para virtualization a hardware environment is not completely simulated by hypervisor but certain changes are made in guest operating system to adaptit to run in virtual environment. The guest OS is modified to change non virtualizable privileged instructions with hypercalls to the hypervisors. Ex - Xen
Hardware-assisted virtualization - Hardware-assisted virtualization is a way of improving the efficiency of hardware virtualization. It involves employing specially designed CPUs and hardware components that help improve the performance of a guest environment. Ex – Intel-VT, AMD-V with hypervisors like KVM, Xen
2.3 Virtual Machine Migration Strategies
In this section, we will consider the most common setting for Live VM Migration [6][7] a clustered server environment. The three main physical resources that are used under such conditions are memory, network and disk. While memory can be copied directly from one host to another, local disk and network interface migration are not trivial. To be able to preserve open network connections and to avoid network redirection mechanisms, a VM should retain its original IP address after migration. If the migration is within the same LAN, which is the norm in a clustered server environment, this can be done by generating an unsolicited ARP reply advertising the new location for the migrated VM's IP.Local disk migration should not be needed inside a server farm. Data centers use network-attached storage (NAS) devices, which can be accessed from anywhere inside the cluster. Thus, secondary storage doesn't have to be migrated with the VM. Consequently, in a clustered server environment, the Live VM Migration problem is reduced to finding a way of consistently transferring VM memory state from one host to another[12].
2.3.1 Memory migration
Memory Migration can be divided into three phases:
Push phase-The source VM continues running while certain pages are pushed across the network to the new destination. To ensure consistency, pages modified during this process must be resent. Stop-and-copy phase-The source VM is stopped, pages are copied across to the destination VM, then the new VM is started.
Pull phase-The new VM starts its execution and, if it accesses a page that has not yet been copied, this page is faulted in across the network from the source VM.Most migration strategies select either one or two of the above phases. While the pre-copy approach combines push with stop-and-copy, the post-copy approach combines pull with
stop-and-copy.
2.3.2 Pre-Copy
Xen uses pre-copy as its live migration strategy. The pre-copy algorithm uses an iterative push phase, followed by a minimal stop-and-copy. The iterative nature of the algorithm is the result of what is known as dirty pages: memory pages that have been modified in the source host since the last page transfer must be sent again to the destination host. At first, iteration i will be dealing with less dirty pages than iteration--1.Unfortunately, the available bandwidth and workload characteristics will make it so that some pages will be updated at a faster rate than the rate at which they can be transferred to the destination host. At that point, the stop-and-copy procedure must be executed. A 5-step view of the pre-copy technique is shown in Fig. 5. The stop-and-copy phase is when the CPU state and any remaining inconsistent pages are sent to the new host, leading to a fully consistent state. Determining the time to stop the pre-copy phase is non-trivial, since there exists a trade-off between total migration time and downtime. If it is stopped too soon, more data must be sent over the network while both the source and the destination are down, leading to a larger downtime. Nonetheless, if stopped too late, sometime will be wasted on pages that are written too often and defeat any pre-copy efforts. As explained by, most server work- loads exhibit a small, but frequently updated set of pages known as writable working set (WWS) or hot pages that can only be transferred during the stop-and-copy stage. Depending on the workload characteristics, registered downtimes with the pre-copy technique of only 60 ms and 210 ms with normal applications, and a worst-case 3.5 second downtime with an intentionally ‖diabolical‖ workload.
Stage0:Pre-Migration: We begin with an active VM on physical host A. To speed any future migration, a tar- get host may be preselected where the resources required to receive migration will be guaranteed.
Stage1: Reservation: A request is issued to migrate an OS from host A to host B. We initially confirm that the necessary resources are available on B and reserve a VM container of that size. Failure to secure resources here means that the VM simply continues to run on A unaffected.
Stage2: Iterative Pre-Copy: During the first iteration, all pages are transferred from A to B. Subsequent iterations copy only those pages dirtied during the previous transfer phase.
Stage3: Stop-and-Copy: We suspend the running OS in- stance at A and redirect its network traffic to B. As described earlier,CPU state and any remaining in consistent memory pages are then transferred. At the end of this stage there is a consistent suspended copy of the VM at both A and B. The copy at A is still considered to be primary and is resumed in case of failure.
Stage4: Commitment: Host B indicates to A that it has successfully received a consistent OS image. Host A acknowledges this message as commitment of the migration transaction: host A may now discard the original VM, and host B becomes the primary host.
Stage5: Activation: The migrated VM on B is now activated. Post-migration code runs to reattach device drivers to the new machine and advertise moved IP addresses. This approach to failure management
ensures that at least one host has a consistent VM image at all times during migration. It depends on the assumption that the original host remains stable until the migration commits, and that the VM may be suspended and resumed on that host with no risk of failure. Based on these assumptions, a migration request essentially attempts to move the VM to a new host, and on any sort of failure execution is resumed locally, aborting the migration.
III LIVE MIGRATION
Live migration shown in Fig.5 moves running virtual machines from one physical server to another with no impact on virtual machine availability to users. By pre-copying the memory of the migrating virtual machine to the destination server, live migration minimizes the transfer time of the virtual machine[7] [9] [10]. A live migration is deterministic, which means that the administrator, or script, that initiates the live migration determines which computer is used as the destination for the live migration. The guest operating system of the migrating virtual machine is not aware that the migration is happening, so no special configuration for the guest operating system is needed.
Figure 5: live migration process
After initiating a live migration, the following process occurs: Live migration setup occurs. During the live migration setup stage, the source server creates a connection with the destination server. This connection transfers the virtual machine configuration data to the destination server. A skeleton virtual machine is set up on the destination server and memory is allocated to the destination virtual machine. Memory pages are transferred from the source node to the destination node. In the second stage of a live migration, the memory assigned to the migrating virtual machine is copied over the network to the destination server. This memory is referred to as the ―working set‖ of the migrating virtual machine. A page of memory is 4 KB. For example, suppose that a virtual machine named ―test virtual machine‖ configured with 1024 MB of RAM is migrating to another server running Hyper-V. The entire 1024 MB of RAM assigned to this virtual machine is the working set of ―test virtual machine.‖ The utilized pages within the ―test virtual machine‖ working set are copied to the destination server. In addition to copying the working set of ―test virtual machine‖ to the destination server, Hyper-V monitors the pages in the working set for ―test virtual machine‖ on the source server. As memory pages are modified by ―test virtual machine,‖ they are tracked and marked as being modified. The list of modified pages is simply the list of memory
pages ―test virtual machine‖ has modified after the copy of its working set has begun. During this phase of the migration, the migrating virtual machine continues to run. Hyper-V iterates the memory copy process several times, with each iteration requiring a smaller number of modified pages to be copied. After the working set is copied to the destination server, the next stage of the live migration begins. Modified pages are transferred. The third stage of a live migration is a memory copy process that duplicates the remaining modified memory pages for ―test virtual machine‖ to the destination server. The source server transfers the CPU and device state of the virtual machine to the destination server. During this stage, the network bandwidth available between the source and destination servers is critical to the speed of the live migration. Using a 1 Gigabit Ethernet or faster is important. The faster the source server transfers the modified pages from the migrating virtual machines working set, the more quickly the live migration is completed. The number of pages transferred in this stage is determined by how actively the virtual machine accesses and modifies the memory pages. The more modified pages there are, the longer it takes to transfer all pages to the destination server. After the modified memory pages are copied completely to the destination server, the destination server has an up-to-date working set for ―test virtual machine.‖ The working set for ―test virtual machine‖ is present on the destination server in the exact state it was in when ―test virtual machine‖ began the migration process. The storage handle is moved from the source server to the destination server. During the fourth stage of a live migration, control of the storage associated with ―test virtual machine,‖ such as any virtual hard disk files or physical storage attached through a virtual Fiber Channel adapter, is transferred to the destination server. (Virtual Fiber Channel is also a new Hyper-V feature in Windows Server 2012.)The virtual machine is brought online on the destination server. In the fifth stage of a live migration, the destination server now has the up-to-date working set for ―test virtual machine,‖ as well as access to any storage used by ―test virtual machine.‖ At this point ―test virtual machine‖ is resumed. Network cleanup occurs. In the final stage of a live migration, the migrated virtual machine is running on the destination server. At this point, a message is sent to the network switch. This message causes the network switch to obtain the new the MAC addresses of the migrated virtual machine so that network traffic to and from ―test virtual machine‖ can use the correct switch port. The live migration process completes in less time than the TCP time-out interval for the virtual machine being migrated. TCP time-out intervals vary based on network topology and other factors. The following variables may affect live migration speed:
The number of modified pages on the virtual machine to be migrated—the larger the number of modified pages, the longer the virtual machine will remain in a migrating state.
Available network bandwidth between source and destination servers.
Hardware configuration of source and destination servers.
Load on source and destination servers.
Available bandwidth (network or Fiber Channel) between servers running Hyper-V and shared storage.
The live migration process for a virtual machine inside a cluster (when the virtual machine is stored on a CSV volume) and for a virtual machine outside of a cluster (when the virtual machine is stored on an SMB share) is
practically identical[13].
When performing a live migration of a virtual machine between two computers with no shared infrastructure, the first thing that Hyper-V does is perform a partial migration of the virtual machines storage, as follows:
Throughout most of the move operation, disk reads and writes go to the source virtual hard disk.
While reads and writes occur on the source virtual hard disk, the disk contents are copied over the network to the new destination virtual hard disk.
After the initial disk copy is complete, disk writes are mirrored to both the source and destination virtual hard disks while outstanding disk changes are replicated.
After the source and destination virtual hard disks are completely synchronized, the virtual machine live migration is initiated, following the same process that is used for live migration with shared storage.
Once the live migration is complete and the virtual machine is successfully running on the destination server, the files on the source server are deleted.
IV REAL TIME SERVICE
The steps for a real-time service are as follows Fig. 6.
Requesting a virtual platform
Generating a RT-VM [11] from real-time applications
Requesting a real-time VM
Mapping physical processors
Executing the real-time applications
V CONCLUSION
We hope this study can provide insights into the performance aspect of various streaming technologies and offer guidelines to cloud operators and end users in implementing them. The Virtualization has brought a new additional feature to cloud computing.
REFERENCES
[1] ―Cloud computing,‖ http://www.ibm.com/cloud-computing/us/en/whatis-cloud computing.html.
[2] Zhiming Shen, Zhe Zhang, Andrzej Kochut, Alexei Karve, Han Chen, Minkyong Kim Hui Lei, Nicholas Fuller, ―VMAR: Optimizing I/O Performance and Resource Utilization in the Cloud‖.
[3] ―Cloud Computing,‖ http://en.wikipedia.org/wiki/Cloud computing.
[4] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. Katz, A. Konwinski, G. Lee, D. Patterson, A. Rabkin, I. Stoica, and M. Zaharia. ―Above the Clouds: A Berkeley View of Cloud Computing,‖ Technical Report EECS-2009-28, EECS Department, Univ.of California, Berkeley, 2009.
[5] K. H. Kim, W. Y. Lee, J. Kim, R. Buyya. ―SLA-Based Scheduling of Bag-of- Tasks Applications on Power-Aware Cluster Systems,‖ IEICE Transactions on Information and Systems, Issue 12, pp. 3194-3201, 2010.
[6] P. Padala, ―Understanding live migration of virtual machines.‖ Available: http://tinyurl.com/24bdaza, Jun. 2010.
[7] D. Breitgand, G. Kutiel, and D. Raz, ―Cost-aware live migration of services in the cloud,‖ in 2011 USENIX Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services. [8] VMWare, ―VMmark Virtualization Benchmarks,‖ http://www.vmware.com/products/vmmark/, Jan. 2010. [9] S.Hacking and B. Hudzia, ―Improving the live migration process of large enterprise applications,‖
inProceedings 2009 International Workshop on Virtualization Technologies in Distributed Computing [10] A. Beloglazov, R. Buyya. ―Energy Efficient Allocation of Virtual Machines in Cloud Data Centers,‖ 10th
IEEE/ACM International Conference on Cluster, Cloud and Grid Computing, pp. 577-578, 2010.
[11] Carlo Mastroianni, Michela Meo, and Giuseppe Papuzzo,‖ Probabilistic Consolidation of Virtual Machines in Self-Organizing Cloud Data Centers,‖ IEEE TRANSACTIONS ON CLOUD COMPUTING, VOL. 1, NO. 2, JULY-DECEMBER 2013
[12] Mladen A. Vouk,‖ Cloud Computing – Issues, Research and Implementations,‖ Journal of Computing and Information Technology - CIT 16, 2008, 4, 235–246
[13] T.Swathi, K.Srikanth, S. Raghunath Reddy,‖ VIRTUALIZATION IN CLOUD COMPUTING,‖ IJCSMC, Vol. 3, Issue. 5, May 2014, pg.540 – 546
