1.

ABSTRACT:
The critical IT infrastructures require non-disruptive operations [2]. The operating systems there on are far from perfect that patches and upgrades are frequently applied, in order to close vulnerabilities, and new features to enhance the performance [2]. To avoid minimize the loss of availability , the operating systems need to provide features such as live update through which patches and upgrades can be applied without having to stop and reboot the operating system [2, 3]. Unfortunately, most current live updating approaches cannot bind to specific design approaches. The virtualization is used to provide the live update capability. This approach allows a broad range of patches and upgrades to be applied at any time without the requirement of steady state. This type of approach shares good portability for its OS-transparency and is suitable for inclusion in general virtualization systems. A working prototype LUCOS [2], which supports live update capability for live update capability on Linux running Xen virtual machine monitor[2, 3, 4]. The kernel patches used for this approach are from Linux kernel 2.6.10 to 2.6.11 [2], and apply some of those kernel patches. Performance overhead is less than 1% performance degradation compared to a Xen-Linux [2]. The time to apply a patch is also very minimal. The demands of high-performance computing (HPC) often mismatch the assumptions and algorithms provided by legacy operating systems (OS) for common workload mixes [3]. The feature- and application rich OSs allow for flexible and low-cost hardware configurations, rapid development, and flexible testing and debugging, the mismatch comes at the cost of performance degradations for HPC applications [2, 3]. The ubiquitous availability of virtualization support in all relevant hardware architectures enables new programming and execution models for HPC applications without losing the comfort and support of existing OS and application environments.

2. LITERATURE SURVEY:
2.1. Virtualization for High-Performance Computing
The demands of high performance computing (HPC) often mismatch the assumptions and algorithms provided by legacy operating systems (OS) for common workload mixes. The application rich OSs allow for flexible and low cost hardware configurations, rapid development, and flexible testing and debugging, the mismatch comes at the cost of performance degradation for HPC applications. The ubiquitous availability [3, 4] of virtualization support in all relevant hardware architectures enables new programming and execution models for HPC applications without losing the comfort and support of existing OS and application environments.

2.2. Xen and the Art of Virtualization

The systems which designed to support virtualization subdivide the resources of a modern computer. Certain systems require specialized hardware or cannot support the operating systems. Virtualization targets the 100% binary compatibility at the expense of performance or sacrifices the security or the functionality for speed. The virtualization also provides the resource isolation, best effort provisioning, risking denial of service. The Virtual Machine Monitor (VMM) which allows multiple commodity operating systems to share conventional hardware in a safe and resource managed fashion, but without sacrificing either functionality or performance.

2.3. Virtualization, Virtually at the Desktop

The computing environment is the ability to allow separate operating system instances and associated software packages to share a single hardware server. The successfully utilized existing off the shelf products and developed tools and protocols to migrate processing tasks from the desktop level to the virtual desktop level running on remote hardware and returning the processing results back to the desktop level for display, all the processing is done at the server level, no need of high performance graphics workstation class machines at the desktop. This offers high performance graphics workstation capabilities to any desktop, including lower end commodity class desktop machines, notebook computers, or even thin clients.

3. COMPREHENSIVE STUDY:
3.1. Virtualization: Virtualization is the creation of virtual (rather than real) version of something, such as an operating system, a server, a storage device or network resources [4, 5]. Methods of Virtualization: y y Full Virtualization and Para Virtualization

Types of Virtualization: y y y Network Virtualization Storage Virtualization and Server Virtualization

Virtual Machine I
Application I Application II Application III Operating System

Virtual Machine II
Application I Application II Application III Operating System

Virtual Machine Monitor Hardware Devices Fig 1: General Structure of Virtualization 3.1.1. Full System Virtualization: It provides a virtual replica of the systems hardware so that operating systems and software may run on the virtual hardware exactly as they would on the original hardware. The first full system virtualization system developed was the CP-67 software system which ran on IBM 360/67 mainframe computer. This program was designed as a specialized time sharing system which exposed to each user a complete virtual system / 360 computer. 3

3.1.2. Para Virtualization: Full virtualization yields the very poor performance. The paravirtualization is a software approach where it modifies the operating system so that instead of going directly to the CPU to perform protected tasks it goes to the VMM. Xen and Denali supports paravirtualization. 3.2. Virtual Machine (VM): It is the way of a time sharing very expensive mainframe computers. It allows the same computer to be shared as if it were several. IBM defined the virtual machine as a fully protected and isolated copy of the underlying physical machines hardware.

3.3. Virtual Machine Monitor (VMM):

The VMM is the software component that hosts guest virtual machines [3, 5 and 6]. The VMM often referred to as the host and the virtual machines as guests [5, 6]. It is the software layer which abstracts the physical for use by the virtual machines. It provides an abstraction; it can run multiple virtual machines on the same system. The VMM provides a virtual processor and other virtualized versions of system devices such as I/O devices, storage, memory, etc. It also provides the isolation between the virtual machines it hosts so the cache coherence is preserved.

3.4. Xen Virtualization:

Xen is a paravirtualization system it has the unique goal of paravirtualizing operating systems such as Linux, NetBSD and Windows XP, rather than supporting its own special operating system [2, 5 and 6,]. Xen aims for 100% binary compatibility for applications running in its virtual machines. Advantages: y y y y y y Partial access to hardware page tables Lower privilege Levels Trap handlers registered with VMM System calls registered with processor No hardware interrupts Generic devices 4

Xen paravirtualization supports the IA-32 or x86 architectural designs [5]. Certain supervisor instructions must be handled by the VMM for correct virtualization, but executing these with insufficient privilege fails silently rather than causing a convenient trap. The paravirtualization improves the performance, although it requires modifications to the guest operating system. It does not require changes to the Application Binary Interface (ABI) [5], and no modifications are required to guest applications.

3.5. Live Updating of Operating Systems:

The patches and upgrades are a part of operating system. Such patches and upgrades are frequently applied in order to plug security holes, add new features and enhance performance. This process requires stopping and restarting a running operating system, which could cause a major source of its loss of availability. Modern operating systems are large and complex. To live update such operating systems safely, updatable units, a quiescent state or a safe point needs to be detected or enforced before a dynamic patch could be applied. Otherwise the operating system may result in an inconsistent state. The existing operating systems are not designed with a live update capability, they implemented with non object oriented approaches. Hence, function calls are often made directly rather than going through an indirection table, making it difficult to redirect function calls. And they usually lack the mechanism that supports safe points detection. It makes a quiescent state detection either very time consuming or simply impractical.

3.6. Live Update Using Virtualization:

Virtualization provides an additional layer between the running operating system and the underlying hardware. The software layer is referred to as the Virtual Machine Monitor (VMM), manages the hardware resources and exporting them to the operating systems running on them. The VMM is in control of the state and the execution of the operating systems. The VMM is used to track and change any state of the OS with the need for a reboot. A live update request is trapped to the VMM which carries out the process of live updates. The benefits of this process are: y y Any trap from the OS to the VMM is synchronized and blocked The OS is totally inactive during the live update until the trap is completed 5

y y

Ensures the atomicity of a live update It eliminates the requirement of a quiescent state and allows patches to be applied at any time

y y

The versions of the data structures will be write protected The live updates executed in the VMM will not cause any state change to the trapped OS

3.6.1. The Framework of LUCOS: The LUCOS [1] is an environment to support live updates to a running operating system [2, 3], it follows certain design principles: 3.6.1.1. OS Transparency and OS Neutral: To avoid disrupting services on a running OS, any change to the OS should not necessitate an OS reboot. The support for live updates in the VMM is OS neutral, allowing good portability. 3.6.1.2. Flexibility: LUCOS allows live updating an OS at the granularity of functions. It also permits updates to code and data structures, even dynamically adding and removing single instance or multiple instances of data structures. Updates are allowed to be performed at any time, even when the code to be updated is still active. 3.6.1.3. Safety and Maintainability: Any update to the OS should be transactional to avoid corrupting the whole system. The system should be able to roll back if an error occurs during the update process. LUCOS allows any previously committed updates to be rolled back. 3.6.1.4. Correctness: LUCOS neither verifies nor validates the input patch files, but assumes its correctness. The verification of the patch files will be done by developers and testers. LUCOS allows rolling back problematic patches or patching the same update units more than once.

3.6.1.5. Patches to Data Structures: To ensure the correctness of the system, it is required that if any change is made to a data structure, any code that manipulates any instance of the data structure should also be updated accordingly. 3.6.1.6. Patches to Function Prototypes: LUCOS changes only callee functions and keeps caller functions intact; its difficult to deal with the case where the function prototype is changed. If there is any change to a functions prototype, its callers are chosen as the candidates for live updates. 3.6.1.7. Patches to Initialization Code and Data: Usually a large number of initialization code and data is present in the operating systems. They are executed only once during the booting process. Their memory space is freed after the startup phase of the operating system [2, 3]. It is difficult to support live updates to such code and data directly because it is impossible to update those data retroactively. These types of updates usually need to take effective only when the OS is restarted next time. There is no need to update such code and data immediately to the running OS. 3.6.1.8. Patches to Scope Information: The scope information of a function restricts the functions accesses to some specific scope. Such a patch generally has no effect on the runtime behavior of the OS kernel. Some may affect the access control rules of the kernel. 3.6.2. Classification of Live Updates: There would be two types of patches to the OS: updates affecting only code, and updates affecting both code and data. Because any change to the data structures requires corresponding changes to the code manipulating them, the type of live updates that change only data is not allowed.

3.6.3. Architecture of LUCOS: It consists of three major components in Fig.2. The control logic for users is separated from the update logic in the OS and the VMM, which gives clear interface and good portability.

User Space

Live Update Control Interface

Operating System

Update manager (Module)

Virtual Machine

Virtual Machine Monitor

Update Server

Hardware Devices

Fig 2: Architecture of LUCOS 3.6.3.1. Control Interface: To make the live update system easy to use, a user friendly control interface is indispensible. It is easy for users to apply updates and rollback existing patches. The control interface lies on top of the OS in the form of a user application. Only authorized users are allowed to use it. It has three options available. y y y Query: shows detailed information of applied patches Patch: apply a new patch Rollback: rollback a committed patch

3.6.3.2. Update Manager: To rollback patches frequently, it is desirable to manage all these operations in a uniform way and to avoid possible errors in the process. Rolling back a nonexistent patch should be caught and disallowed, or it may corrupt the OS. The different versions of the patch to the same functions are properly managed. To allow a patch that involves multiple functions, there should be a mechanism to allow a patch that involves multiple functions within the patch be grouped and committed together. The update manager serves as an agent or a proxy between the control interface and the update server. It is in the form of a loadable kernel module in the OS. It provides the following services: y y y . Receive patch commands from the control interface and verify their legitimacy To process live updates it negotiates with the update server It manages the committed patches and coordinates different versions of the patches to the same function A live update command is sent to the update server in the form of a hypercall. A hypercall is a synchronous software trap that carries out the control transfer from the OS to the VMM on which it runs. The synchronous nature of the hyper call ensures that the OS is inactive in its entirety during the live update process in VMM 3.6.3.3. Update Server: It carries out the live updating of code and data. It receives all the necessary information from the update manager. The function of this is redirecting the function calls, setting up the necessary data structures to maintain the coherence among different versions of data, invoking the state transfer functions. The update server is composed of several hypercall handlers that service the corresponding live update requests. It is responsible for guaranteeing the coherence between the original and the new data if the live update changes the data structures. The update server invokes the corresponding state transfer function supplied by the update manager to maintain coherence.

4. INFERENCES:
y y With virtualization multiple OSs can safely coexist on one physical machine Virtualized machine is multiplexed by a small privileged kernel, referred to as a hypervisor or Virtual Machine Monitor (VMM) y Live migration of running OSs decouple software installation from the physical hardware configuration by Virtual devices y The consolidation of virtualization is less relevant to HPC workloads, virtualization enables the specialization of OSs with almost full control over hardware resources y A quiescent state or a safe point needs to be detected or enforced before a dynamic patch could be applied y y The VMM modifies the state of the OS without having to stop and reboot the OS The data structures of the OS will be write protected by the VMM

5. INNOVATIONS:
y To increase the efficiency of virtual devices, need to implement a shared universal Buffer [5] indexed on block contents y To provide better physical memory performance, a last chance page cache (LPC) [5], should be implemented y The first instance on writing network and block device drivers, with the aim of fully supporting enterprise servers such as IIS [5] y The update LUCOS which supports the updates to data only

10

6. CONCLUSION:
Virtualization, that is increasingly attractive for commercial systems, as implemented by a small hypervisor that runs below the usual OS layer, has the same potential to benefit HPC applications in the dimensions of flexible OS variety, productivity, performance, reliability, availability, security and simplicity. Using virtualization to live update a running OS on demand, without the requirement of a quiescent state. The prototype LUCOS is able to live update the Linux without disrupting its services and with minimal overhead during the normal execution. The node failures on contemporary computers can often be anticipated by monitoring health and detecting a deteriorating status.

7. REFRENCES:
[1] Arun Babu Nagarajan, Frank Mueller, Christian Engelmann , Stephen L. Scott, Proactive Fault Tolerance for HPC with Xen Virtualization ACM seattle, june 18-20,2007. [2] Haibo Chen, Rong Chen, Fengzhe Zhang, Binyu Zang, Pen-Chung Yew, Live Updating Operating Systems Using Virtualization. ACM VEE06 June 1416, 2006.

[3] Mark F. Mergen, Volkmar Uhlig, Orran Krieger, Jimi Xenidis, Virtualization for HighPerformance Computing. IBM T.J. Watson Research Center, pages 8-11,2008.

[4] Kaushik Kumar Ram, Jose Renato Santos, Yoshio Turner, Alan L. Cox Scott Rixner, Achieving 10 Gb/s using Safe and Transparent Network Interface Virtualization, ACM VEE09 pages 61-70, March 11-13, 2009.

[5] Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauery, Ian Pratt, Andrew War_eld Xen and the Art of Virtualization Microsoft Research Cambridge, Intel Research Cambridge, UK, ACM SOSP03, October 19-22, 2003.

[6] Karissa Miller, Mahmoud Pegah Virtualization, Virtually at the Desktop ACM SIGUCCS07, pages 255-260 October 7-10, 2007.

11