software rejuvenation

CHAPTER 1

INTRODUCTION TO SOFTWARE REJUVENATION IN

COMPLEX SYSTEM

1.1 Introduction

Industry uses high complex system environment, which tends to software aging. Availability is

the critical issue for system failure, which causes system degradation, to avoid this issue software

rejuvenation technique is used, we use optimal rejuvenation technique for dynamically solving

aging problem based on variable workload and timer policy, performance degradation,

crash/hang, failure may occur due to data corruption, numerical errors and maximum use of

system resource unnecessarily, this leads to software degradation which is known as software

aging [1].

If the load increases system may tends to crash that is software aging occurs. That is solved by

software rejuvenation technique; software rejuvenation [2] is proactive fault management

technique to clear system errors and prevent system from failures in future.

This project implements different software rejuvenation techniques depending on variable

workload and optimize rejuvenation time, Rejuvenation time is calculated depending on variable

workload which is given by system. System periodically checks the workload and update to

rejuvenation manager. Figure 1.1 shows the architecture of Rejuvenation manager, it is consists

of aging detector which detects the software aging point and optimizer to optimize the timer

value for a point of rejuvenation. Aging detector and optimizer has two components namely

variable workload and timer policy which perform their defined function respectively. Aging

detector obtains the value provided by rejuvenation manager periodically and checks for the need

for change in rejuvenation time depending on workload and this is updated for rejuvenation

manager, if there is need for change in rejuvenation time then rejuvenation manager allows

optimizer to change the time, the function of optimizer is to optimize the time depending the

values provided by aging detector based on workloads.

Figure 1.1 System architecture used for software rejuvenation in complex system

Analysis of performance, dependability of complex systems is done through SPNP (Stochastic

Petri Net Package) [2].Weight cardinality arc; guarded function of a complex system is

constructed through SPNP.

A state can be reached by all other states becomes irreducible in Marko chain [2]. A CTMC

(Continuous Time Markov Chain) [3] is ergodic if it is irreducible and if a state is reached by all

other state recursively in finite period. Steady state analysis underlying ctmc is done by SPNP

[3], and few measures related to steady state are not considered as their values can be obtained

by steady state probability.

Software rejuvenation process can be done in different methods namely cold and warm .In cold

OS reboot process, the system is rebooted immediately at rejuvenation point. Rejuvenation point

is a point where memory consumption of system reaches a threshold value or predetermined

time. When system consumes high amount of ram the OS must be rebooted, clearing all internal

states. Memory consumption may be done by applications or error prone codes which run for

long time consuming large amount of ram or OS itself.

In OS warm reboot process, before rebooting the kernel state is saved, including all applications

running on kernel, their sates are saved .saving the kernel state is done by creating a complete

image of kernel.

Approaches to Software Rejuvenation

Software rejuvenation can be divided broadly into twoapproaches as follows.

Time based approach [4][5][6]:

In this approach, rejuvenationis performed without any feedback from the system. Rejuvenation

in this case, can be based just onelapsed time (periodic rejuvenation) and/or instantaneous

cumulative number of jobs on the system.

Time and workload approach [4][5][6]:

In this approach, rejuvenation is performed based on information on thesystem “health”. The

system is monitored continuously (in practice, at small deterministic intervals) anddata is

collected on the operating system resource usageand system activity. This data is then analyzedto

estimate time to exhaustion of a resource whichmay lead to a component or an entire system

degradationcrash. This estimation can be based purely on time or can be based on both time and

systemworkload. Time is optimized based on workload applied and it is updated to system

rejuvenation time.

1.2 Motivation:

• Current systems are reactive if a failure occurs necessary steps will be taken to handle it

but they can’t detect such a failure beforehand. Our project aims to detect such failure

proactively using Time and workload techniques and take action before a given node

crashes.

• Our project determines if a node is going to fail based on RAM utilization and then it

rejuvenates the failing node. Our project analyze and identifies these failing nodes using

both Time and load balancing Rejuvenation techniques.

1.3 State of Art Development

Complex system is a form of ubiquitous computing deals with providing everything as a service.

Complex system mainly used in business and IT industry it offers heavy outsourcing model

computational resource, where service availability, security and quality are essential features. In

Complex system High service availability is the most important requirement increasingly being

demanded in commercial computer, and communication systems.

In recent years many research efforts have been going to find the optimal infrastructure size and

configuration that guarantee the desired availability level. Software fault tolerance is often found

to be the bottleneck. A failure in software’s is mainly due to certain elusive error conditions

which it leads to resource exhaustion. Software systems appear to age as error conditions arise

and accumulate with operational time due to certain elusive faults in system software and

application software. Software rejuvenation is a proactive fault management technique aimed at

cleaning up the internal states in order to prevent the occurrence of severe crash failures in the

upcoming years the simplest way to emulate software rejuvenation is to reboot the system or

restart the aging application. It is a cost effective technique dealing with software faults that

includes protection not only against hard failures and also due to degradation over time of

application performance.

1.3.1 Classification of software faults:

Faults, in both hardware and software, can be classified according to their phase of creation or

occurrence, system boundaries (internal or external), domain (hardware or software). In this

section, we limit ourselves to the classification of software faults based on their phase of creation

.some studies have suggested that since software is not a physical entity, it is not focusing to

transient physical phenomena (as opposed to hardware), hence software faults are stable in

nature [1].some other studies organizes software faults as both permanent and transient.

Gray [2] categorizes software faults into Bohrbugs and Heisenbugs. Bohrbugs is essentially

stable design faults and hence, approximately it is deterministic in nature. They can be

recognized easily and weeded out during the testing and debugging phase (or early deployment

phase) of the software life cycle. A software system with Bohrbugs is related to a faulty

deterministic finite state machine. Heisenbugs, on the other hand, fit into the class of temporary

internal faults and are intermittent.

They are essentially stable faults whose conditions of creation occur rarely or are not easily

recreated. Hence these types of faults result in transient failures i.e., failures which may not

occur again if the software is restarted. Heisenbugs are extremely difficult to identify through

testing. Hence a piece of software which is developed in the operational phase gets released after

its development and testing phase, is more likely to be experienced with failures caused by

Heisenbugs than due to Bohrbugs.

Most modern studies on failure data have reported that a large percentage of software failures

are transient in nature caused by phenomena such as overloads or timing and exception errors.

The revise of failure data from Tandem’s fault tolerant computer system indicate that 70% of

the failures were transient failures, caused by faults similar to race conditions and timing

problems. We designate faults attributed to software aging as aging related faults. Aging related

faults fall under Bohrbugs or Heisenbugs depending on whether the failure is deterministic

(repeatable) or transient [3]. Foraging-related bugs, environment diversity can be particularly

effective if utilized proactively in the form of software rejuvenation. Rejuvenation operation

can be triggered either by time based (on deterministic intervals) or by using measurement and

analysis of data of the system condition that undergoes software aging problems in various

workstation environments.

1.3.2. Basic concepts of software aging and software rejuvenation:

Software aging is defined as the state of the software that degrades with time. The primary

causes of this degradation are the exhaustion of operating system resources, data corruption,

and accumulation of numerical errors, which eventually may lead to performance degradation

of the software, crash/hang failure, or both.

A typical example of software aging is progressive increase in memory consumption which

conclusively causes a memory leak. Since software aging can be observed only in the software

execution, it is difficult to find aging related problems until the software is deployed and

executed in a specific environment. This figure describes the threads which lead to aging

related failure in the system.

Figure 1.2 Aging Related failure

The accumulation of AR (aging related) errors may tend to AR failure or fault. Aging effects

can also be classified into volatile and non-volatile effects. They are considered volatile if they

are isolated by re-initialization of the system or process affected, for example via a system

reboot. In contrast, non-volatile aging effects still exist after reinitializing of the

system/process. Physical memory division and OS resource outflow are examples for volatile

aging effects. File system schema and database metadata fragmentation are examples for non-

volatile aging effects [4]. The fault tolerance technique which is used to mitigate the aging

effects of system is known as software rejuvenation.

Software rejuvenation is defined as occasionally stopping the running software, cleaning its

internal state or its environment and restarting it. Such a technique known as software

rejuvenation was proposed by Huang which counteract the aging phenomenon in a proactive‖

manner by removing the accumulated error conditions and freeing up of operating system

resources. Garbage collection, flushing operating system kernel tables, and reinitializing internal

data structures are some examples by which the internal state or the environment of the software

can be cleaned. There are basically two approaches followed for Software rejuvenation and for

finding the optimum rejuvenation schedule: first is by analytic model and measurement based

rejuvenation. The analytic modelling approach assumes failure and repair time distributions of a

system and obtains optimal rejuvenation Schedule to maximize the availability, or minimize the

loss probability or downtime of cost. Measurement-based rejuvenation approach is based on

monitoring of resource consumption in a computer system and analysis of that data to determine

the point of time when a resource will be completely exhausted, thereby causing the system to

hang/crash. Measurement based Software

AR Bugs

Aging Factors

AR Error

System Internal

Environment

AR Failure

Activates Propagates

Rejuvenation can follow any of the following policies: Purely Time based Software

Rejuvenation Policy (PTSRP) or Purely Prediction based Software.

Figure 1.3 Rejuvenation Scheduling

1.3.3 Rejuvenation technique

In this section, we review the three VMM rejuvenation techniques. When VMM rejuvenation

needs to be performed on a host, the hosted VMs also need to be controlled because the

execution environments of VMs are cleared by the VMM rejuvenation. Prior to VMM

rejuvenation, we can perform VM shutdown (i.e., Cold-VM rejuvenation), VM suspend (i.e.,

Warm-VM rejuvenation), or VM migration (i.e., Migrate-VM rejuvenation). These approaches

are presented in the next three subsections.

1.3.3.1 Cold-VM rejuvenation

The easiest way to deal with the hosted VMs before triggering rejuvenation of VMM is to shut

down all the hosted VMs regardless of the execution states of the VMs. The VMs are then

Software rejuvenation Scheduling

Time-Based Inspection-Based

Threshold Based Prediction based

Mixed Approach

Statistical Structural

Models and Statistical

Machine Learning

Online | Offline Online| Offline

Online| Offline

Online |Offline

Online |Offline

Online |Offline

restarted in clean states after the VMM rejuvenation. This approach is called Cold-VM

rejuvenation. All the transactions running on VMs are vanished by the Cold-VM rejuvenation

[6]. An advantage of the Cold-VM rejuvenation, however, is that the rejuvenation action cleans

all the aging states of the VMs in addition to the aging states of the VMM

1.3.3.2 Warm-VM rejuvenation

Instead of shutting down the hosted VMs, the hosted VMs are suspended prior to VMM

rejuvenation is triggered and the executions of the VMs are resumed at the completion of the

VMM rejuvenation. We call this technique Warm-VM rejuvenation [5]. Since the execution

states of the hosted VMs are saved prior to VMM rejuvenation, the transactions running on the

VMs are not lost due to the VMM rejuvenation. However, Warm-VM rejuvenation retains the

aging states of VMs by VM suspend. The aging states in the hosted VMs are not cleared by

VMM rejuvenation and hence we need to rely on rejuvenation for VM to clear the aging states of

VMs.

1.3.3.3 Migrate-VM rejuvenation

Live VM migration is a technique to move a running VM to another host incur a short service

interruption and is supported in most modern VMM implementations such as Xen and VMware.

Although a shared storage system is required to store a VM image, the downtime overhead

caused by a VM migration is less. Using live VM migration, hosted VMs are moved to another

host prior to VMM rejuvenation and returned back to the original hosting server after the

completion of the rejuvenation of the VMM, by a reverse live VM migration. We call this

combined method as Migrate-VM rejuvenation [6]. The VM continues the execution even

while the VMM on the original host is being rejuvenated. However, the aging states in the hosted

VMs are not cleared by the VMM rejuvenation as in the case of Warm-VM rejuvenation. Live

VM migration works only when the migration target server is running and it has a capacity to

accept the migrated VM. Comparison of different software rejuvenation policy is described in

table 1.1

Table 1.1 Comparison of different software rejuvenation policy

Policy Aging Condition Analysis Tool

Threshold value

Availability Methodology

Or

Model

Constrained Element Based Software Rejuvenation Policy In Embedded Environment (CESRP)

To detect aging CESRP uses CPU frequency

- - -- - - - -- -

W (Shapiro-walk Detection) = 0.9781

Pvalue = 0.8453

Probability density µ=8450.16

Stack result

σ=1830.731

Constrained path and Constrained element with mathematical model

Gray’s classification of software faults

Hear aging is detected by time base depending on result of an operating system resources

SNMP (Simple Network Management Protocol) based on distributed resource monitoring tool

• Mean time to recover from a failure = 4 hours

• Mean time to rejuvenate the system = 1 hour

• Mean time to failure = 41.38 days

• Cost of failure = $5000/hour

• Cost of rejuvenation = $500/hour

σ∗ (Optimal availability) = 36.12 days

σ (Down

time) = 5.60 days

Semi-markov reward model based on workload and resources

POMDP (Partially Observable markov decision process)

Aging detected based on the degradation level of system

- - -- - - - -- -

POMDP K = 1

0.9951

POMDP K = 4

0.9932

POMDP K = 9

0.9901

CMTC (Continues Time Markov Chain) model

POMDP K = 99

0.9901

Software rejuvenation based on automated self-healing techniques

Aging can be detected based on

1.Online transaction processing

(OLTP) servers,

2.Middleware applications and Web/application-servers

SAN (Stochastic Active Network)

- - -- -

- - -- -

Basic steady-state availability = 0.824673

Tolerance availability = 0.983678

This policy consists of six methodology

• System under test

• Fault model.

• Fault-remediation relationship.

• Micro-measurements.

• Macro-measurements.

• Workload and metric collectors.

Component-

Dependency

based Micro-

Rejuvenation

Scheduling

Policy

An aging can detected based on utilization of system resources, such as memory,

SAN Model

- - -- - - - -- -

micro-rejuvenation scheduling

1.4 Problem Statement:

• Performance degradation in the complex system running for a long time

• They are susceptible to crash because of data corruption, numerical error accumulation

and availability of OS resources.

• Thus, leading to downtime and non-optimal performance.

• Based on vary in workload the rejuvenation time is optimized to reduce the down time

and increase the availability of the system.

1.5 Objectives of the project:

• The main objective of this project is to reduce software failure rates, avoid downtime and

to improve the system availability using Software rejuvenation policy based on time and

load balancing scheme using ITL algorithm.

• Availability of the system for various rejuvenation techniques is analyzed.

• Analysis of different rejuvenation technique is done, based on values obtained from

SPNP

1.6 Scope of the work:

1.6.1 Limitations of the project:

• Hardware compatibility is required.

• Same hardware configurations are required on end systems.

• Worked on open source tools and packages.

1.6.2 Constraints of the project:

• Rejuvenation time and memory peak value is set based on the machine learning studies.

• Hardware virtualization must be supported.

• Systems must support NFS( Network File Shared).

1.7 Methodology :

• Implementation of a proactive based appraoch for software rejuvenation using Time and load

balancing schema based techniques.

• SRN modelled graphs were used for analysis of algorithm on all modules.

• Physical Memory utilization is considered for implementing the Time and Workload based

approaches.

• Designed ITL algorithm makes use of timer and variable workload policy to present the time-

based rejuvenation for performing dynamic adaptation of the rejuvenation timer based on the

workload conditions.

• ITL algorithm is used to optimize rejuvenation time defined by user when workload is

variable.

• Availabilty of the system of different modules is derived based on different parameters

obtained from SPNP.

• Live migration of virtual machine is done using KVM/QEMU.

• NFS is configured on two servers to migrate the VM.

Figure 1.4 Optimization

of rejuvenation

time for variable

workload

Figure 1.4 describes

ITL algorithm to

optimize the rejuvenation

time (VT) with respect

to system workload

(WL). Based on variation

of workload WL+1 the

rejuvenation time has to be optimized to VT+1. If the system workload is back to the normal

condition WL+2, the optimizer has to optimize the rejuvenation time to VT+2.

1.8 Organization of the Report:

This report contains 8 chapters.

• The first chapter deals with the Introduction to the project. It covers the purpose,

motivation and scope for the project. It also talks about the methodology adopted and the

literature survey undertaken.

• The second chapter primarily deals theory and concepts of software rejuvenation in

complex system.

• The third chapter primarily deals with the software and hardware requirements

specifications required for the project. It is the software requirements document.

• The fourth chapter explains the design of the system proposed in the project. It gives a

detailed overview of the components used in the project.

• The fifth chapter describes the implementation of the project. It discusses the difficulties

encountered while coding the project and the coding standards used.

• The sixth chapter focuses on testing the application so that it is a robust product. Various

tests are conducted on the all modules.

• The seventh chapter presents the results of the classification and comparison. Analysis of

all modules is done here.

• The eighth chapter gives the conclusion of the project. It deals with the limitations of the

product and the future enhancements possible in the project.

CHAPTER 2

THEORY AND CONCEPTS OF SOFTWARE

REJUVENATION IN COMPLEX SYSTEM

2.1 Introduction

Software rejuvenation has become a new horizon for increasing the system reliability and

availability in a long run. With time, the system outages tend to increase due to the aging of

software which may be caused due to numerous factors like memory leaks, unreleased locks, file

descriptor leaking and so on. The rejuvenation of the software based on time factor tends to

periodically rollback a continuously running application to prevent failures in the future. The

time factor is set a particular value after which the software is restarted. Thus the better way to

avoid software failure and to increase the availability and reliability of the system is to find the

failure probable state and rejuvenate the software prior to the failed state. Project investigates

about time based rejuvenation policies in maintaining high reliability of software systems.

Software rejuvenation is a process or act of gracefully terminating a running application and

restarting it. The main motive behind the rejuvenation process is to prevent any unexpected

errors which might be caused due to aging related issues of the software. So the idea of the

software rejuvenation is to suspend the application and restart it before it suffers any error. The

rejuvenation strategy is primarily intended for servers where the applications are intended to run

incessantly for days without any failure. Software aging involves the gradual degradation of

application performance over time that may lead to untimely cessation of the program. The main

objective of the process is to maintain higher system reliability and availability by cleaning

internal system states prior to the failure state of the application.

2.2 Software Rejuvenation Techniques Review

Software rejuvenation technique takes in account different types of approaches. Broadly these

are classified as: Standard rejuvenation, Delayed rejuvenation and Mixed rejuvenation.

2.2.1 Standard Rejuvenation

In Standard rejuvenation, rejuvenation occurs once triggering interval is reached. This

rejuvenation policy does not take workload into consideration i.e., there is no concern of

workload. This strategy ignores both i.e. Peak load or off peak load and the rejuvenation

happens on triggered time.

2.2.2 Delayed Rejuvenation

In delayed rejuvenation, on peak load nodes are scheduled for rejuvenation if the rejuvenation

time is reached during peak period, the actual rejuvenation is started as soon as the next off peak

period starts.

2.2.3 Mixed Rejuvenation

The mixed rejuvenation policy is the combination of standard rejuvenation strategy and delayed

rejuvenation strategy. If the rejuvenation is timed early in peak period, rejuvenation of the

application is done immediately or else the rejuvenation is delayed till the next off period starts.

2.2.4 Erlang Approximation

Based on workload, i.e., peak load and off peak load, different time policy methods are

established to solve the quest for finding the interval need for scheduling. In standard

rejuvenation, neglecting peak load or off peak load rejuvenation occurs on triggered time. In

delayed rejuvenation as defined above the delayed time is obtained by Erlang distribution. DSPN

becomes a markovian stochastic Petri net and the solution techniques for markov chains can be

applied. The deterministic switching time between peak and off-peak periods is kept as it is,

hence this model is a DSPN (Deterministic and stochastic petri nets).

The rejuvenation is triggered at every time units, and is modeled by the deterministic transition,

with constant firing time. When deterministic transition is fired, and if the immediate transition is

enabled at that time, the token will be moved to another place, indicating a beginning of

rejuvenation activity. Standard rejuvenation, timer is always enabled, while for delayed

rejuvenation, timer is disabled during peak period, and for mixed rejuvenation, timer is enabled

for the initial time duration of certain length and disabled thereafter in peak period. After the

rejuvenation finishes, reset will fire to return a token back to its place, hence beginning the next

rejuvenation cycle. In order to make the model solvable by SPNP approximate the deterministic

transition by an r- stage Erlang distribution. This is achieved by storing r tokens in other place

and replacing deterministic timer by an exponentially distributed timed transition with firing rate

r/timer. At the same time, they change the multiplicities to r for the output arc of reset timer and

the input arc of timer policy.

2.3 Stochastic Reward Nets Model for Time based Software

Rejuvenation in Virtualized Environment

Here we are mainly focused on the unplanned software outages due to software aging problem.

We present a comprehensive availability model for both VM clustering software rejuvenation

model and VM migration based software rejuvenation model. In this model captures software

aging states of VM and VMM as well as their failures caused by aging. Using analytical

modeling as a stochastic reward nets (SRN).

In this model we describe our proposal to offer high availability mechanism using time based

software rejuvenation methodology. First we present the ways of using virtualization to improve

software rejuvenation for addressing the software aging issue. In the proposed system,

virtualization technology and software rejuvenation are used to provide the availability of the

services.

Clustering supports two or more servers running duplicate VMs. Failover technologies also

allow a failed VM to load from a storage snapshot and start up on another server. To counteract

the software and hardware failure, the rejuvenation schedules for VM and VMM need to

determine in proper way for the VM availability, since VMM rejuvenation effects VMs running

on the VMM. The following two scenarios are studied in this paper.

2.3.1 VM Clustering Software Rejuvenation (2vms1pm)

Physical machine hosts the virtual machines. One monitoring VM and other operational VMs on

the top of the virtualization layer (VMM) are created. The main application server will be

running on one VM and the remaining VM will be used for standby server. Some software

modules that will be responsible for the detection of software aging are installed in the

monitoring VM. The monitoring VM will trigger a rejuvenation operation. If the active VM is

about to be rejuvenated, standby VM will be started and then all the new requests and sessions

are switched from the active VM to standby VM. So the physical machine itself is a SPOF

(single point of failure).

2.3.2 VM Migration Based Software Rejuvenation (2vms2pms)

In this scenario Active-standby virtualized clustering architecture is employed. A high available

cluster is built between two or more virtual machines, each of them running on different physical

machines (2 PMs). Two PM’s consists of Active physical server and standby physical server.

Both physical servers can access shared storage. A heartbeat keep-alive system is used to

monitor the interaction of VMs and the physical servers. At active physical server, VMs are

created as monitoring VM, active VM and standby VM as well as standby physical server. Both

VM and VMM time-based rejuvenation mechanism is considered in this scenario. Time based

rejuvenation policy for VM is same as active-standby VMs hosted on 1PM.

Live VM migration enables a running VM on a host server to move onto the other host server

with very small interruption of the execution. When VMM need to be rejuvenation, the hosted

VMs can move onto other physical server. It can return back to the original host after the

completion of the VMM rejuvenation by live VM migration again. In the event of an active

physical server outage, the virtualized recovery server at standby physical server can be activated

to take over the running of the workload immediately using live migration. The down time of a

VM caused by live VM migration is very small and the VM continues the execution even while

the original host is down.

CHAPTER 3

SOFTWARE REQUIREMENT SPECIFICATION OF

SOFTWARE REJUVENATION IN COMPLEX SYSTEM

3.1 Project Description

Software Rejuvenation in Complex System has six different modules namely OS Cold reboot,

OS Warm reboot, VM Cold reboot, VM Warm reboot, VMM reboot, VM migration. Each

module consist of unique working method, which is explained below

3.2 Module Description

There are mainly six modules, they are: OS cold reboot, OS warm reboot, VM cold reboot, VM

warm reboot, VM migration, VMM reboot.

3.2.1 Module for OS Cold rejuvenation:

In Cold OS reboot process, the system is rebooted immediately at rejuvenation point.

Rejuvenation point is a point where memory consumption of system reaches a threshold value or

predetermined time. When system consumes high amount of ram the OS must be rebooted,

clearing all internal states. Memory consumption may be done by applications or error prone

codes which run for long time consuming large amount of RAM or OS itself

In this process the memory left is compared to our pre-determined threshold value, if the

memory left is greater than the threshold value, the system is allowed to run in normal state i.e.

Systems have not reached the threshold point of consumption. If it is lesser i.e. the system have

consumed memory greater than the threshold point, then OS is restarted immediately

The amount of free memory left is extracted and compared with predetermined threshold free

memory value, on results of comparison obtained; further process is taken care by ITL

algorithm.

3.2.2 Module for OS warm rejuvenation:

In OS warm reboot process, before rebooting the kernel state is saved, including all applications

running on kernel, their sates are saved .saving the kernel state is done by creating a complete

image of kernel.

OS reboot process is divided in two stages 1) Suspend, 2) Resume. In Suspend stage kernel is

called to create a snapshot of current system state later snapshot data is written to disk, finally

system is rebooted. In Resume stage, when the system is turned on, grub loader runs from initrd

before mounting any partitions, later all the data of snapshot is read from disk and loaded to

kernel, kernel restores the image and thus system runs from same state where it was suspended.

3.2.3 Module for VM cold reboot:

In VM cold reboot process [9], the VM is rebooted immediately at rejuvenation point, hypervisor

is untouched. Rejuvenation point is a point where memory consumption of system reaches a

threshold value or predetermined time. When VM consumes high amount of ram the VM must

be rebooted, clearing all internal states. Memory consumption may be done by applications or

error prone codes which run for long time consuming large amount of RAM or OS itself

ITL algorithm compares the memory left to our pre-determined threshold value, if the memory

left is greater than the threshold value; the system is allowed to run in normal state i.e. System

have not reached the threshold point of consumption. If it is lesser i.e. the system have consumed

memory greater than the threshold point, then rejuvenation time is optimized and updated to

predetermined time, when rejuvenation time is equal to system time then VM is restarted

immediately without saving any state of running VM.

3.2.4 Module for VM warm reboot:

In VM warm reboot process, before rebooting the kernel state of particular failing VM is saved,

including all applications running on kernel, their sates are saved .saving the kernel state is done

by creating a complete image of kernel.

VM Warm reboot process is divided in two stages 1) Suspend, 2) Resume. In Suspend stage

kernel is called to create a snapshot of current system state later snapshot data is written to disk,

finally system is rebooted. In Resume stage, when the system is turned on, grub loader runs from

initrd before mounting any partitions, later all the data of snapshot is read from disk and loaded

to kernel, kernel restores the image and thus system runs from same state where it was

suspended. Here this module provides decrease in request failures and high availability to the

VM.

ITL algorithm compares the memory left to our pre-determined threshold value, if the memory

left is greater than the threshold value; the system is allowed to run in normal state i.e. System

have not reached the threshold point of consumption. If it is lesser i.e. the system have consumed

memory greater than the threshold point, then rejuvenation time is optimized and updated to

predetermined time, when rejuvenation time is equal to system time then VM is restarted

immediately saving state of running VM.

3.2.5 Module for VMM reboot

In VMM cold reboot process, the VMM is rebooted immediately at rejuvenation point, all the

VM’s running on VMM are shut down before rebooting VMM. Rejuvenation point is a point

where memory consumption of system reaches a threshold value or predetermined time. When

VMM consumes high amount of RAM the VMM must be rebooted, clearing all internal states.

Memory consumption may be done by applications or error prone codes which run for long time

consuming large amount of RAM.

In this process ITL algorithm compares the memory left to our pre-determined threshold value, if

the memory left is greater than the threshold value, the system is allowed to run in normal state

i.e. System have not reached the threshold point of consumption. If it is lesser i.e. the system

have consumed memory greater than the threshold point, then rejuvenation time is optimized and

updated to predetermined time, when rejuvenation time is equal to system time then VM is

restarted immediately without saving any state of running VM, If VMM memory consumption

reaches its peak point i.e. VMM tending to crash in soon time then VMM is restarted even if all

VM is running in normal state and no state, data is saved but user is given period of one minute

user can cancel the rebooting process or shutdown the VMM completely.

3.2.6 Module for VM Migration [10] [11] [12]

In this module, VM from the failing server is transferred to preconfigured secondary server

before the VM tending to fail, the complete data and application running on the main server is

transferred to the secondary with no interruption for application running. When the complete VM

is transferred to another server and loaded, all the applications which were running in main

server will be in same state even after transferred, with no loss of data of applications running.

As this is all done by configuring NFS for both servers and configuring virtual manager and

virish packages initially, applying this concept to our project, when the server get huge load of

request or high memory is consumed which may lead to hang/crash or failure of the system,

when user set the rejuvenation time and threshold memory value, rejuvenation manager checks

for aging problem in system and if aging problem is detected then the rejuvenation time

predetermined by user is optimized by ITL algorithm and system is rejuvenated at rejuvenation

time, here for rejuvenation we use migration technique to migrate the VM running and reboot the

server, hence we provide high availability and decrease in request failure.

3.3 Software requirements:

Table 3.1 Software requirements

3.4 Hardware Requirements:

Table 3.2 Hardware Requirements

3.5 Performance Requirements:

• Availability

The system shall achieve 100 percent availability at all time.

• Portability

Minimum Requirements

OS Cent OS

Ubuntu OS

Other KVM/QEMU must be installed on both the servers.

NFS must be configured on both the system to migrate the VM

Note: KVM is a hypervisor or Virtual Machine Monitor, NFS (Network

File System) is distributed file system protocol.

Language C

Minimum Requirements

Processor Intel Pentium or better

Memory 4 GB RAM

Hard Disk 100 GB of hard disk space required.

Display 1024x 768 or higher-resolution display with 16 bits colors

The system should be implemented by the java so it can move easily from one system another system because it is purely platform independent.

• Scalability

The system shall uses in multiple approaches.

• Maintainability

The sys00tem should be optimize for supportability, or ease of maintenance as for as possible. This may be achieved through the use documentation of coding standard, naming conventions, class libraries and abstraction.

3.6 Functional requirements:

As per the functional requirement specifications, the project shall provide following facilities

• The system collects the current status of the workload based on the RAM utilized by the

running application.

• Check the aging factor which degrades the availability to application. If any aging factor

detected then it will notify.

• The system collects the status of the system periodically.

• This system keeps track of the system time and it is compared with fixed rejuvenation

schedule. If the tracking time is equal to fixed rejuvenation schedule then the system rejuvenated.

• This system stores the current status of the process; it is useful to again resume the

processor after system rejuvenation takes place.

3.7 Project Effort Estimation:

Assumptions:

Average Labor Cost : $680/month

Average Line of Code (LOC) : 450LOC/month

Average cost for a line of code : $1.5/LOC (680 / 450)

Modules Details:

The Project contain 6 model each model contain around 490 loc/module in which

implementation consists of 320 loc/module and analysis consists of 170 loc/module.

Total Project Size = 490 * 6

= 2940 loc

Cost Estimation:

For one module, cost = 490 * 1.5

= $ 735

Total cost of Project = 2940 * 1.5

= $ 4410

Effort Estimation:

Effort = Total Project Cost

Average people Cost per month

= 4410 / 680

= 6.4852 ≈ 7 Persons/month

7 Persons are required to complete this project in one month duration.

3.8 Project Scheduled:

Table 3.3 Required Schedules for each Task

Figure 3.1 Gantt chart of Project Schedule

CHAPTER 4

HIGH LEVEL DESIGN OF


A software product is a complex entity. Its development usually follows what is known as

Software Development Life Cycle (SDLC). The second stage in the SDLC is the Design stage.

The objective of the design stage is to produce the overall design of the software. The design

stage involves two sub-stages namely:

• High-Level Design

• Detailed-Level Design

In the High-Level Design, the proposed functional and non-functional requirements of the

software are studied. Overall solution architecture of the solution is developed which can

handle those needs.

4.1 Development Methods:

The development method used in this software design is the modular/functional development

method. In this, the system is broken down into different modules, with a certain amount of

dependency among them. The input-output data that flows from one-module to another will

show the dependency.

Data flow diagrams have been used in the modular design of the system.

4.2 Data Flow Diagrams:

Data-flow models are an intuitive way showing how data is processed by a system. At the

analysis level, they should be used to model the way in which data is processed in the existing

system. The notation used in these models represents functional processing, data stores and

data movements between functions. Dataflow models are used to show how data flows

through a sequence of processing steps. The data is transformed at each step before moving on

to the next stage. These processing steps or transformation are program functions where

dataflow diagrams are used to document a software design

4.3 Data Flow Diagram:

4.3.1 Data Flow Diagram For rejuvenation Manager: Level 0

Figure 4.1 DFD: Level 0: module for Rejuvenation system

Rejuvenation process

1.0

REJUVENATION MANAGER

System

In these figure 4.1 Level 0 modules for rejuvenation describes about main rejuvenation process with variable time and workload policy implemented. The different module is selected initially here and later threshold time and threshold memory is set.

4.3.2 Data Flow Diagram for FTR and FTM: Level 1

Figure 4.2 DFD: Level 1 module for rejuvenation manager

In Figure 4.2, the Level1 data flow diagram describes about the working of rejuvenation

manager, rejuvenation manager has two modules namely aging detector and optimizer. Aging

detector detects the aging factor and invokes optimizer to optimize the rejuvenation time. If

aging is not detected then system is rejuvenated at rejuvenation time

System

1.1

1.2

Optimizer

Aging detector

User set Threshold values

Rejuvenation Process

4.3.3 Data Flow Diagram: Level 2

Figure 4.3 Data Flow Diagram: Level 2 module for aging detector

System1.1.1

Call Meminfo ()

1.1.2

Checking the aging factor

Rejuvenation process

SystemOptimizing FTR value

Compare FTR with STM

Rejuvenation Process

1.2.4

1.2.1

1.2.2

1.2.3

Calculate memory

factor

Analyze Current FTR

Figure 4.4 Data Flow Diagram: Level 2 module for time optimizer

Aging detector detects the free memory left by calling meminfo( )and againg result is given to

rejuvenation manager. Rejuvenation manager compares the free memory left to threshold

value given by user, and then it calls the optimizer to optimize the rejuvenation time if

comparison results are positive. Optimizer fetches the FTR and STM (System Time) and checks

for the free memory left. Based on the threshold value, time is optimized, either increased or

decreased.

4.4 Sequence Diagram

A sequence diagram in Unified Modeling Language (UML) is a kind of interaction diagram that

shows how processes operate with one another and in what order. It is a construct of a Message

Sequence Chart. Sequence diagrams are sometimes called Event-trace diagrams, event scenarios,

and timing diagrams

A sequence diagram shows, as parallel vertical lines ("lifelines"), different processes or objects

that live simultaneously, and, as horizontal arrows, the messages exchanged between them, in

the order in which they occur. This allows the specification of simple runtime scenarios in a

graphical manner.

In fig 4.5, clearly depicts the policy used in this project i.e. variable time and workload policy.

Rejuvenation manager request for status of workload applied on the system. System ping the

rejuvenation manager with workload applied on it, then the rejuvenation manager calls aging

detector [13] to compare with predetermined threshold value if any variations observed then

this result is given back to rejuvenation manager, later optimizer is invoked to optimize the

rejuvenation time, and system is allowed to rejuvenate to its optimized time. If no variation is

observed then system is allowed to rejuvenate at predetermined rejuvenation time.

Figure 4.5 Sequence Diagram for rejuvenation manager

4.5 Detailed Design

4.5.1 Detailed System Design

The main aim of the project is to build a simulator used to simulate the Time and Prediction

based rejuvenation approaches.

In this section, the individual modules that comprise the building blocks of the system are

identified and have presented a complete design for them. The details of the design process for

each module contains of the following elements:

• The purpose of the module

• A description of its functionality

• A description of the types and number of inputs it accepts

• A description of the types and number of outputs it generates

4.5.2 Module 1: OS cold reboot

This module is about OS cold reboot, in cold reboot process the rejuvenation time is entered by

user and this time is compared with system time, if there is any variation in workload compared

to threshold value given by user then time is optimized and system is rejuvenated at optimized

time without

Input

The input for the module is rejuvenation time and threshold value of memory.

Output

The output for the module is to rejuvenate at rejuvenation point

Figure 4.6 Functioning of OS cold reboot

Yes No

ART

Compare

Mem_cC

Declare and retrieve time

Reboot

STOP

The functioning of the cold reboot is described in the above flow diagram.

The figure 4.6 shows the process of how OS cold reboot process works, initially user need to set

rejuvenation time and threshold memory value and next comparison of system time with

rejuvenation time given by user, if time is equal then system is rejuvenated immediately. If time

is not equal then memory usage is compared with threshold memory value in block mem_c, if

result is negative then system is rejuvenated if result is positive then time is optimized and

updated to rejuvenation time.

4.5.3 Module 2: Module for OS warm reboot process

This module is about OS warm reboot

Input

The input for the module is to set predetermined rejuvenation time and threshold memory

value.

Output

The output of the module is to save the state of the kernel as image and save it on hard disk

and rejuvenate at rejuvenation time later system must start with from previous reboot state.

The functioning of OS warm reboot is described in the following flow diagram.

Yes No

Yes

No

Start

Save

Rejuvenation

Stop

Optimize

Set FTR & FTM

FTR check

Check FFM

Figure 4.7 Module of OS warm reboot

The figure 4.7 shows how OS warm reboot works. First user have to set the predetermined

rejuvenation time and threshold value of memory, next comparison of system time with

rejuvenation time given by user, if time is equal then kernel state is saved and stored in hard

disk and system is rejuvenated. If time is not equal then memory usage is compared with

threshold memory value in block check FFM (Fixed Free Memory) if result is negative then

system time is checked with rejuvenation time. If result is positive then time is optimized and

updated to rejuvenation time. System is rejuvenated at the rejuvenation time.

4.5.4 Module 3: VM cold reboot.

This module describe about VM cold reboot.

Input


value.

Output

Output for the module is to rejuvenate the VM at the rejuvenation time

The functioning of the VM cold reboot module is described in the following flow diagram.

Mem_C

NoYes

START

Compare

Declare and retrieve time

Reboot

STOP

Yes No

Figure 4.8 Module for VM cold reboot

The figure 4.8 shows module for VM cold reboot is shown, initially user need to set

rejuvenation time and threshold memory value. Next, compare system time with rejuvenation

time given by user, if time is equal then VM is rejuvenated immediately. If time is not equal

then memory usage is compared with threshold memory value in block mem_c, if result is

positive then system is rejuvenated if result is negative then time is optimized and updated to

rejuvenation time.

4.5.5 Module 4: module for VM warm reboot

Input


value.

Output

The output of the module is to save the state of the fault VM’s kernel as image and save it on

hard disk and rejuvenate at rejuvenation time later VM must start from previous reboot state.

The functioning of the VM warm reboot module is described in the following flow diagram.

Figure 4.9 VM warm reboot Module

The figure 4.9 shows VM warm reboot process , First user have to set the predetermined

rejuvenation time and threshold value of memory, next comparison of system time with

Yes No

Optimize

START

Save

Rejuvenation

STOP

Set FTR and FTM FTMChe

ck FTR Check

FTR Check FTM

Check FTM

Resume

Yes No

rejuvenation time given by user, if time is equal then kernel state is saved and stored in hard

disk and system is rejuvenated. If time is not equal then memory usage is compared with

threshold memory value in block named check FTM (Fixed Threshold Memory), if result is

negative then system time is checked with rejuvenation time. If result is positive then memory

usage is compared with peak memory value in block named check FTM, if result is positive then

kernel state is saved and stored in hard disk and system is rejuvenated, if result is positive then

time is optimized and updated to rejuvenation time. System is rejuvenated at the rejuvenation

time

4.5.6 Module 5: module for VM migration

This module describe about VM migration.

Input


value.

Output

Output for the module is to migrate the VM from server which is tending to fail to the another

server at the rejuvenation time

The functioning of the VM migrate module is described in the following flow diagram.

Figure 4.10 VM migration module

NoYes

Yes No

Optimize

Migrate

STOP

Set FTR and FTMSet FTR and FTM

Che

ck FTR Check

FTR Check FTM

Check FTM

STARTSSTART

No

Yes

The figure 4.10 shows flow chart of VM migration clearly depicts it working, initially admin need

to set the rejuvenation time and threshold memory value where the VM must be migrated,

here whatever the application running and dynamic data entered in VM will be migrated

successfully to the secondary server configured, so this module will provide most availability to

the server. Once when rejuvenation time is set and if heavy workload applied to the server in

mean time then the rejuvenation time is optimized so the server will be protected from

hang/crash failure. When rejuvenation time is reached the complete VM will be migrated to

another server configured, as data and application running are non-corrupted this module

provide no request failure and high availability, which is in great need to current corporate

world.

4.5.7 Module 6: Module for VMM reboot

This module describe about VMM reboot.

Input


value.

Output

Output for the module is to rejuvenate the VMM at the rejuvenation time

The functioning of the VMM reboot module is described in the following flow diagram.

Mem_C

NoYes

START

Compare

Set FTR and FTM

Reboot

STOP

Yes No

Figure 4.11 VMM reboot model

The figure 4.11 shows the process of VMM reboot, initially user need to set rejuvenation time

and threshold memory value and next comparison of system time with rejuvenation time given

by user, if time is equal then system is rejuvenated immediately. If not then depending on the

workload system will optimize the rejuvenation time, at an optimized time VMM reboot takes

place. In this module before VMM reboot, all the VM’s running are shut down.

CHAPTER 5

IMPLEMENTATION OF


The implementation phase of any project development is the most important phase as it yields

the final solution, which solves the problem at hand. The implementation phase involves the

actual materialization of the ideas, which are expressed in the analysis document and developed

in the design phase.

Project has six modules OS Cold reboot, OS Warm reboot, VM Cold reboot, VM Warm reboot,

VM Migration and VMM reboot, based on Time and Workload rejuvenation policies and also

analysis of all the modules are done using SPNP (Stochastic Petri Nets Package).

5.1 Platform Selection:

5.1.1 KVM/QEMU:

KVM (Kernel-based Virtual Machine) is a full virtualization solution for Linux on x86 hardware

containing virtualization extensions (Intel VT or AMD-V). It consists of a loadable kernel

module, kvm.ko that provides the core virtualization infrastructure and a processor specific

module, kvm-intel.ko or kvm-amd.ko. KVM also requires a modified QEMU although work is

underway to get the required changes upstream.

Using KVM, one can run multiple virtual machines running unmodified Linux or Windows

images. Each virtual machine has private virtualized hardware: a network card, disk, graphics

adapter, etc.

The kernel component of KVM is included in mainline Linux, as of 2.6.20.KVM is open source

software. A wide variety of guest operating systems work with KVM, including many flavours

of Linux, BSD, Solaris, Windows, Haiku,ReactOS, Plan 9, and AROS Research Operating

System. In addition Android 2.2, GNU/Hurd (Debian K16), Minix 3.1.2a, Solaris 10 U3, Darwin

8.0.1 and more OSs and some newer versions of these with limitations are known to work. A

modified version of QEMU can use KVM to run Mac OS X.

5.1.2 SPNP (Stochastic Petri Net Package) [12][13] [14]:

This package was developed by Ciardo et.al. The model type used for input is a SRN (Stochastic

Reward Net). SRNs incorporate several structural extensions to GSPNs such as marking

dependencies (marking dependent arc cardinalities, guards, etc.) and allow reward rates to be

associated with each marking. The reward function can be marking dependent as well.

They are specified using CSPL (C based SRN Language) which is an extension of the C

programing language with additional constructs for describing the SRN models. SRN

specifications are automatically converted into a Markov reward model which is then solved to

compute a variety of transient, steady-state, cumulative, and sensitivity measures. For SRNs with

absorbing markings, mean time to absorption and expected accumulated reward until absorption

can be computed.

The interface increases the power of SPNP (Stochastic Petri Net Package) [15] by providing a

means of rapidly developing stochastic reward nets (SRNs); the model type used for input. Input

to SPNP is specified using CSPL (C based SPN Language), but the interface removes this burden

from the user by providing an interface for graphical representation of the model.

The first interface was implemented with Tcl/Tk. Then JAVA was used develop the new version,

which makes the look and feel of the interface.

5.1.3 CentOS (OS selection)

The CentOS Linux distribution is a stable, predictable, manageable and reproducible platform

derived from the sources of Red Hat Enterprise Linux (RHEL). The process delivered has a clear

governance model, increased transparency and access.

Since March 2004, CentOS Linux has been a community-supported distribution derived from

sources freely provided to the public by Red Hat. As such, CentOS Linux aims to be functionally

compatible with RHEL. CentOS change packages to remove upstream vendor branding and

artwork. CentOS Linux is no-cost and free to redistribute.

CentOS Linux is developed by a small but growing team of core developers. In turn the core

developers are supported by an active user community including system administrators, network

administrators, managers, core Linux contributors, and Linux enthusiasts from around the world.

We adopt this OS because it is highly compatible and stable, it is very easy to install KVM and

configure it. Moreover configuring NFS is easy for beginners and ports can be resolved properly.

The forums of this OS had all the solutions to problems we have faced in other OS like Ubuntu,

fedora. Moreover it is open source and codes are available online.

5.2 Programming Language Used (Language Selection):

C is a general-purpose programming language initially developed by Dennis Ritchie. C is

an imperative (procedural) language. It was designed to be compiled using a relatively

straightforward compiler, to provide low-level access to memory, to provide language constructs

that map efficiently to machine instructions, and to require minimal run-time support. C was

therefore useful for many applications that had formerly been coded inassembly language, such

as in system programming.

Despite its low-level capabilities, the language was designed to encourage cross-

platform programming. A standards-compliant and portably written C program can be compiled

for a very wide variety of computer platforms and operating systems with few changes to its

source code. The language has become available on a very wide range of platforms, from

embedded microcontrollers to supercomputers.

Table 5.1 Methods used in code

Methods used in code Description

void meminfo(void) Used to check system free memory status.

FILE_TO_BUF(meminfo.file, memif_id) Used to store intermediate results of memory

status

stroul( ) Used to convert string to unsigned long integer

time( ) Used to get current system time. This function

return time_t type variable.

memcopy( ) Used to convert time_t struct variable totm_d

struct variable.

loacaltime( ) Used to fetch system local time.

Sizeof To get object size

System( ) This function is used to invoke system

command fprintf( ) This function used to write to file.

fopen( ) This function is used to create a file

5.3 Installing and configuring KVM on cent OS

5.3.1 Check Hardware Virtualization support

KVM requires hardware virtualization support such as Intel VT or AMD's AMD-V, which

are instruction set extensions for hardware-assisted virtualization. Check if hardware

virtualization support is available on CentOS host machine:

$ egrep -i 'vmx|svm' --color=always /proc/cpuinfo

If CPU flags contain "vmx" or "svm", it means hardware virtualization support is

available.

5.3.2 Configure FQDN for local host

Configure FQDN (Fully Qualified Domain Name) for local host. Otherwise, you may get

warnings while launching libvirtd daemon such as "getaddrinfo failed for 'myhost': Name

or service not known".

To configure FQDN, edit the following configuration file:

$ sudo -e /etc/sysconfig/network

HOSTNAME=xxx.yyy

5.3.2.1 Disable SELinux

Before installing KVM, be aware that there are several SELinux Booleans that can

affect the behavior of KVM and libvirt. Here we set Selinux to 0 "Permissive" for

demonstration purpose. If you do not wish to change SELinux mode.

To disable SELinux on CentOS:

$sudo -e /etc/selinux/config

SELINUX=permissive

5.3.2.2 Reboot the machine for the change to take effect.

5.4 Install KVM, QEMU and user-space tools

To install KVM, QEMU and user-space tools use the following steps:

Step1: Install KVM and virtinst (a tool to create VMs) as follows:

$sudo yum install kvm libvirt python-virtinst qemu-kvm

Step2: Start libvirtd daemon, and set it to auto-start:

$sudo service libvirtd start

$sudo chkconfig libvirtd on

Step3: Check if KVM has successfully been installed. You should see no error as

follows.

$ sudo virsh -c qemu:///system list

Id Name State

----------------------------------------------------

Step4: Configure Linux Bridge for VM Networking

Installing KVM alone does not allow VMs to communicate with each other or access

external networks. You need to configure VM networking separately. Here, we set up

"bridged networking" via Linux Bridge.

Install a package needed to create and manage bridge devices:

$sudo yum install bridge-utils

Disable Network Manager Service if it's enabled, and switch to default net manager as

follows.

$sudo service NetworkManager stop

$sudo chkconfig NetworkManager off

$sudo chkconfig network on

$sudo service network start

To configure a new bridge, you have to pick an active network interface (e.g.,

eth0), and enslave it to the bridge. Depending on whether the network interface is

assigned an IP address via DHCP or statically, there are two different ways to

configure a new bridge.

To configure bridge br0 via DHCP:

$sudo -e /etc/sysconfig/network-scripts/ifcfg-eth0

• Modify the file ifcfg-etho as shown below:

DEVICE=eth0

TYPE=Ethernet

ONBOOT=yes

NM_CONTROLLED=yes

BRIDGE=br0

$sudo -e /etc/sysconfig/network-scripts/ifcfg-br0

• Modify the file ifcfg-br0 as shown below:

DEVICE=br0

NM_CONTROLLED=yes

ONBOOT=yes

TYPE=Bridge

BOOTPROTO=dhcp

You should now see br0 bridge interface with a proper IP address as follows.

$ifconfig

Step5: Install VirtManager

The final step is to install a desktop UI called VirtManager for managing virtual

machines (VMs) through libvirt.

To install VirtManager:

$ sudo yum install virt-manager libvirt qemu-system-x86 openssh-askpass

libcanberra-devel

5.5 Setup a minimal CentOS 6 NFS configuration

To setup an NFS (Network File System) configuration for two systems, basically we have

to consider one system as a server and another one as a client. The following steps show

the NFS Server configuration:

5.5.1 SERVER CONFIGURATION:

Step1: Checking for yum updates and installing NFS utils

• To setup the server: 172.16.30.48/255.255.255.254

• Before setup the server system needs update the packages:

"yum update"

• Once update is completed reboot the system.

"shutdown -r now"

• Install nfs-utils rpcbind system configuration package.

"yum install nfs-utils rpcbind system-config-firewall-tui"

• Modify the selinux file to disable SELINUX

"vi /etc/sysconfig/selinux" and set "SELINUX=disabled".

"setenforce 0"

Step2: Make a folder to be shared

In an NFS sharing we have to create folder, that folder is shared with the both the server and

client. That folder holds all the data which is transferred between server and client

Here we are creating and sharing a folder called image, in the below command we are giving

the path in which where that folder is present.

$ mkdir /var/lib/libvirt/images

Step3: Checking the configuration of nfs, nfslock, and rpcbind:

$ chkconfig nfs on

$ chkconfig nfslock on

$ chkconfig rpcbind on

Step4: Configure the firewall setting:

$ "system-config-firewall-tui"

Step5: Modify the exports file to add the shared storage to make live migration from

source to destination system

/var/lib/libvirt/images 172.16.30.48/255.255.255.254 (rw, sync, no_root_squash)

Step6: Modify the hosts.allow file by following lines:

$ sudo /etc/hosts.allow

mountd: 172.16.30.46/255.255.255.254

Step7: Modify the hosts.deny file by following lines

portmap:ALL

lockd:ALL

mountd:ALL

rquotad:ALL

statd:ALL

Step8: Restart the following services on Server machine once you completed all the

above steps:

$ sudo service rpcbind restart

$ sudo service nfs restart

$ sudo service nfslock restart

Once you finish serve configuration, immediately follow the client configuration.

To configure the NFS client follow the following steps:

5.5.2 CLIENT CONFIGURATION:

Step1: To Setup the Client: 172.16.30.46/255.255.255.254

• Before we setup the client, system need to be updated with other packages:

$ sudo yum update

• Once update is completed reboot the system.

$ sudo shutdown -r now

• Install nfs-utils rpc bind system configuration package.

$ sudo yum install nfs-utils rpcbind system-config-firewall-tui

• Modify the selinux file to disable SELINUX

$ sudo gedit /etc/sysconfig/selinux and set SELINUX=disabled

$ setenforce 0

Step2: Make a folder to be the mount point.

In an NFS sharing we have to create sharable folder, this folder is shared with the both the

server and client. This folder holds all the data which is transferred between server and client

Here we create and share a folder called image, in the below command we give the path in

which where that folder is present.

$ sudo mkdir /var/lib/libvirt/images

Step3: Start the following services

$ sudo chkconfig nfs on

$ sudo chkconfig nfslock on

$ sudo chkconfig rpcbind on

Step4: Restart the following services on Server machine once you completed all the

above steps:

$ sudo service rpcbind restart

$ sudo service nfs restart

$ sudo service nfslock restart

Once you finish the both server and client NFS configuration, we have to mount the folder which

is created during the NFS server and client configuration.

To mount a folder we have to use the following steps:

Step1: Append the following line to fstab file:

$ sudo gedit /etc/fstab

<Shared directory> <mount point> <type> <auto> 0 0

172.16.30.48://var/lib/libvirt/images /var/lib/libvirt/images nfs auto 0 0

172.16.30.48: Server name

172.16.30.48:/var/lib/libvirt/images: mount File

/var/lib/libvirt/images: Mounting point on client machine (172.16.30.46)

nfs : Type

Step2: Mount shared nfs file on client machine:

$ sudo mount -t nfs 172.16.30.48://var/lib/libvirt/images /var/lib/libvirt/images.

5.6 ITL Algorithm.

ITL algorithm is designed to optimize the rejuvenation time predefined by user when workload is

variable. Rejuvenation time is decreased when workload increases and rejuvenation time is

increased when workload decreases.

Working of algorithm is described in below steps

Step 1: Begin

Step 2: Set variable FTR (Fixed Time Rejuvenation)

Step 3: Fetch the system Free Memory and assign to variable FM (Free Memory)

Step 4: Set the Threshold Free Memory value to variable FFM (Fixed Free Memory)

Step 5: if (FTR==SystemCurrentTime)

Then Reboot

Else

If (FM < FFM) then

Reset the FTR= FTR-(1*(FM-FFM))

Step 6: Go to Step 5

Step 7: End

CHAPTER 6

TESTING OF SOFTWARE REJUVENATION IN COMPLEX SYSTEM

6.1 Testing

There are essentially three main domain and six modules in our project. In this section the results

of all six modules are being tested with different OS, VM or VMM. The purpose of this section

is to ensure that the resulting system meets the system requirements and there is a seamless

transition of data flowing through each of the systems as well as in between one another.

These testing provide a sort of "living document". Clients and other developers looking to learn

how to use the module can look at these tests to determine how to use the module to fit their

needs and gain a basic understanding of the modules.

6.1.1 Testing Strategy

The following points are indicative of the testing strategy for unit testing followed in the project.

• Review the design specifications and source code for modules to be tested.

• Perform a peer review on the module Test Plan.

• Create any test "stubs" required to provide input to or receive output from the code

module.

• When it's time to test particular modules, compile the code in the test environment to

check for any missing files required for test plan execution.

• Execute the tests. Compare information/values received out of the tested software to

those expected, as documented in the Test Plan.

• Retest code when an updated version is available. Record results on the module Test

Report Form.

• When the module is considered to have passed all tests, archive the final Report form(s).

Table 6.1: Cold reboot based on Time

Table 6.2: Cold reboot based on Workload

Test Case ID T-2

Test Case ID T-1

Purpose The system should rejuvenate at given rejuvenation time(TTR)

Pre-Conditions System time

Inputs Time to Rejuvenate(TTR)

Expected Output Reboot

Post-Conditions After rebooting the system the current state should not be saved

Execution History

Date Result Version Remark17-02-2014 Pass 1.0 Testing passed in Ubuntu 12.04 operating system15-03-2014 Pass 1.0 Testing passed in CentOS operating system27-03-2014 Pass 1.0 Testing passed in Ubuntu 12.04 operating system04-04-2014 Pass 1.0 Testing passed in CentOS operating system09-04-2014 Pass 1.0 Testing passed in Ubuntu 12.04 operating system09-04-2014 Pass 1.0 Testing passed in CentOS operating system

Purpose System should rejuvenate at given memory threshold value

Pre-Conditions System free memory

Inputs Memory threshold value



Execution History


.

Table 6.3: Cold reboot based on both Time and Workload

Test Case ID T-3

PurposeThe system optimize the rejuvenation time based on the workload and then system

rejuvenates at an optimized time

Pre-Conditions System time and Free memory

Inputs Time to Rejuvenate(TTR) and Memory threshold value



Execution History


Table 6.4: Warm reboot based on Time

Test Case ID T-4

Purpose The system should rejuvenate at given rejuvenation time(TTR)




Post-Conditions After rebooting the system the current state should be saved

Execution History

Date Result Version Remark

27-02-2014 Failed 1.0Testing Failed in CentOS operating system due to OS is not compatible

28-03-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0427-03-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0404-04-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0409-04-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0409-04-2014 Pass 1.0.1 Testing passed in Ubuntu 12.04

Table 6.5: Cold reboot based on Workload

Test Case ID T-5

Purpose The system should rejuvenate at given Memory threshold value

Pre-Conditions System Free memory


Expected Reboot

Output


Execution History




Table 6.6: Warm reboot based on both time and Workload

Test Case ID T-6

PurposeThe system optimize the rejuvenation time based on the workload and then system

rejuvenates at an optimized time

Pre-Conditions System Time and Free memory

Inputs Time to Rejuvenate and Memory threshold value



Execution History



28-03-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0427-03-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0404-04-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0409-04-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0409-04-2014 Pass 1.0.1 Testing is passed in Ubuntu 12.04

Table 6.7: VM cold reboot based on Time

Test Case ID T-7

Purpose The Virtual Machine(VM) should rejuvenate at given rejuvenation time(TTR)



Expected Output Virtual Machine(VM) Reboot

Post-Conditions After rebooting the Virtual Machine(VM) the current state should not be saved

Execution History

Date Result Version Remark27-03-2014 Pass 1.0 Testing passed in Ubuntu 12.04 operating system04-04-2014 Pass 1.0 Testing passed in CentOS operating system09-04-2014 Pass 1.0 Testing passed in Ubuntu 12.04 operating system09-04-2014 Pass 1.0 Testing passed in CentOS operating system

Table 6.8: VM cold reboot based on Workload

Test Case ID T-8

Purpose The Virtual Machine(VM) should rejuvenate at given Memory threshold value





Execution History

Date Result Version Remark27-03-2014 Pass 1.0 Testing passed in Ubuntu 12.04 operating system

04-04-2014 Pass 1.0 Testing passed in CentOS operating system09-04-2014 Pass 1.0 Testing passed in Ubuntu 12.04 operating system09-04-2014 Pass 1.0 Testing passed in CentOS operating system

Table 6.9: VM cold reboot based on both Time and workload

Test Case ID T-9

PurposeThe system optimize the rejuvenation time based on the workload and then Virtual

Machine(VM) rejuvenates at an optimized time





Execution History


Table 6.10: VM warm reboot based on Time

Test Case ID T-10

Purpose The Virtual Machine(VM) should rejuvenate at given rejuvenation time(TTR)




Post-Conditions After rebooting the Virtual Machine(VM) the current state should be saved

Execution History


Table 6.11: VM warm reboot based on Workload

Test Case ID T-11

Purpose The Virtual Machine(VM) should rejuvenate at given Memory threshold value





Execution History


Table 6.12: VM warm reboot based on both Time and workload

Test Case ID T-12


Machine(VM) rejuvenates at an optimized time





Execution History


Table 6.13: VMM reboot based on Time

Test Case ID T-13

PurposeThe Virtual Machine Monitor(VMM) should rejuvenate at given rejuvenation

time(TTR)



Expected Output Virtual Machine Monitor(VMM) Reboot

Post-Conditions

After rebooting the Virtual Machine Monitor(VMM) connection between VMM and VM’s should loss

Execution History


Table 6.14: VMM reboot based on Workload

Test Case ID T-14

PurposeThe Virtual Machine Monitor(VMM) should rejuvenate at given Memory

threshold value



Expected Output Virtual Machine Monitor(VMM) Reboot

Post-Conditions


Execution History


Table 6.15: VMM reboot based on both Time and Workload

Test Case ID T-15


Machine Monitor(VMM) rejuvenates at an optimized time



Expected Virtual Machine Monitor(VMM) Reboot

Output

Post-Conditions


Execution History


Table 6.16: VM migration based on Time

Test Case ID T-16

PurposeThe Virtual Machine(VM) should migrate from one Physical Machine(PM1) to

another Physical Machine(PM2) at given rejuvenation time(TTR)



Expected Output

Virtual Machine(VM) should migrate from one Physical Machine(PM1) to another Physical Machine(PM2)

Post-Conditions

After the migration Virtual Machine(VM) from Physical Machine(PM1) should reboot

Execution History


27-02-2014 Failed 1.0Testing Failed in Ubuntu 12.04 operating system due to OS is not compatible



30-03-2014 Pass 1.0.1 Testing passed in CentOS operating system04-04-2014 Pass 1.0.1 Testing passed in CentOS operating system09-04-2014 Pass 1.0.1 Testing passed in CentOS operating system

Table 6.17: VM migration based on workload

Test Case ID T-17

PurposeThe Virtual Machine(VM) should migrate from one Physical Machine(PM1) to

another Physical Machine(PM2) at given Memory threshold value



Expected Output


Post-Conditions


Execution History






Table 6.18: VM migration based on both Time and workload

Test Case ID T-18

Purpose

The system optimize the rejuvenation time based on the workload and then Virtual Machine(VM) should migrate from one Physical Machine(PM1) to another

Physical Machine(PM2) based on optimized time

Pre-Conditions System Free memory and System Free memory

Inputs System Time and Memory threshold value

Expected Output


Post-Conditions


Execution History






CHAPTER 7

RESULTS OF SOFTWARE REJUVENATION IN COMPLEX SYSTEM

7.1 Results

ITL algorithm implemented on all modules is analyzed using SPNP, which help to get the value

of MTTR and MTTF, from these values, we calculate the availability and downtime factor for

particular algorithm implied to the system. Availability value is found out for all modules and

based on these values we can analyze how much time the system will be available for usage

without any failure.

In SPNP we need to develop a petri net diagram for particular algorithm and for this diagram we

are supposed to code in CSPL (C language based on stochastic petri net) to define the transition

of tokens from one place to another through timed transitions or immediate transitions. Token

are deposited in place and are transmitted from one place to another by timed or immediate

transitions.

To check that petri net diagram is having proper flow, SPNP provide the animation option where

we are supposed to code for guiding token transitions, when and where to move i.e. from one

place to another place. when the code is executed the animated petri net diagram will show how

the transition are taking place , if any error occur during this animated transition then it is clear

that the algorithm or petri net diagram for that algorithm is error prone.

Table 7.1: symbol conventions.

Figure 7.1: Memory model Figure7.2: Clock model

Table 7.2: Clock and Memory SRN model description

Places & Transitions

Description

Pclock Place where clock is initialized or reset.

Ptpolicy This place indicates the rejuvenation time is reached when token is present in it.

Symbol Conventions

Place

Timed transition

Immediate transition

Arc

Tpolicy

Ttrigger

Pclock

Ptrigger

Ptpolicy

Tclock

Ptpolicy

Tmem

Tmemv

Pmem

Ptrigger This place is point for rejuvenation.

Pmem Place where RAM utilization is compared with threshold value predefined.

Pmemv Place which indicates RAM utilization reached its threshold point

Tclock Timed transition, it is enabled when the given time is reached

Tpolicy Timed transition, it is enabled when the token is present in Ptpolicy

Ttrigger Immediate transition, it is enabled when the token is present in Ptrigger and if the given time is reached.

Tmem Timed transition, it is enabled when the given time is reached

Tmemv Immediate transition, it is enabled when the token is present in Ptpolicy and if the given time is reached.

Figure 7.3: OS Cold SRN model.

Table 7.3: OS Cold SRN model description

Trej

tarej

Working

Twork

Rej

Taginig

aging

Figure 7.4: OS Warm SRN model

Table 7.4: OS Warm SRN model description

Places & Description


Description

Working Place which indicates system is in normal working state.

Aging Place which indicates system is suffering from aging problem.

Rej Place which indicates system is under rejuvenation process.

Trej Immediate transition, it is enabled when the given time is reached

Twork Timed transition, it is enabled when the token is present in Rej

Taging Timed transition, it is enabled when the token is present in working and Pmemv.

tarej Immediate transition, it is enabled when the token is present in aging.

Tsave

Taging

Working

Toptiwork

optimizeT

optiaging

saveTrejRej

Tresume

Treworking

Resume

Transitions




Optimize Place where time is optimized based on workload.

Save Place where image of kernel is created and saved.

Resume Place where kernel image saved is retrieved.


Topti Immediate transition, it is enabled when the token is present in aging

Toptiwork Timed transition, it is enabled when the token is present in optimize.

Tsave Timed transition, it is enabled when the token is present in working and Ptpoicy.

Trej Immediate transition, it is enabled when the token is present in save.

Tresume Timed transition, it is enabled when the token is present in rej.

Trewoking Immediate transition, it is enabled when the token is present in resume.

Figure 7.5: VM cold SRN model

Table 7.5: VM Cold SRN model description

T_opt Optimize

T_aging

Aging Rejuvenation

T_rej


Description



Rejuvenation Place which indicates system is under rejuvenation process.



Trej Timed transition, it is enabled when the token is present in Ptpolicy and if the given time is reached.

T_aging Timed transition, it is enabled when the token is present in aging.

T_opt Timed transition, it is enabled when the token is present in Optimize.

T_rej Timed transition, it is enabled when the token is present in Rejuvenation.

Tmem

Aging

Taging

Optimize

Topt

Working

Tsave

Tsave

Save Trej

Rejuvenation

Resume

Tres

Tmem

Working

Aging

Taging

Optimize

Topt

Working

Tsave

Tsave

Save Trej

Rejuvenation

Resume

Tres

Tmem

Aging

Taging

Optimize

Topt

Working

Tsave

Tsave

Save Trej

Rejuvenation

Resume

Tres

Memory

Figure 7.6 VM warm SRN model

Table 7.6: VM Warm SRN model description


Description



Rejuvenation Place which indicates system is under rejuvenation process.


Save Place where image of VM is created and saved.

Resume Place where VM image saved is retrieved.

Memory Place where indicates the vary in memory

Taging Timed transition, it is enabled when the token is present in aging.

Tmem Timed transition, it is enabled when the token is present in memory.

Tsave Timed transition, it is enabled when the token is present in Ptpolicy and if the given time is reached.

T_save Timed transition, it is enabled when the token is present in memory and pmemv==2.

Trej Timed transition, it is enabled when the token is present in save.

Tres Timed transition, it is enabled when the token is present in Rejuvenation.

Twmem Timed transition, it is enabled when the token is present in Pmemv and if the given time is reached.

Trevert Timed transition, it is enabled when the token is present in Resume.

Topt Timed transition, it is enabled when the token is present in optimize.

Tmem

Aging

Taging

Optimize

Topt

Working

Tsave

Tsave

Save Trej

Rejuvenation

Resume

Tres

Tafail

Tnormal

agingfailed

Tafail

aging

Taging

migrate

Tmigrate

Working 1

Trej1

Trejre2

Rej

Trejre1

Trej2

Trevert

Working 2

Thyper

Figure 7.7 VM migration SRN model

Table 7.7: VM Migration SRN model description

Places & Transitions Description

Working1 Place which indicates system is in normal working state.

Working2 Place which indicates system is in normal working state.




migrate Place which indicates VM is getting migrated

Tmaging Timed transition, it is enabled when the token is present in aging.

Tmigrate Timed transition, it is enabled when the token is present in working1.

Trej1 Timed transition, it is enabled when the token is present in working1==1 and if the given time is reached.

Trej2 Timed transition, it is enabled when the token is present in working1 and pclock and if the given time is reached.

Trejre1 Timed transition, it is enabled when the token is present in working1 and rej.

Trejre2 Timed transition, it is enabled when the token is present in rej and working2==0.

Trevert Timed transition, it is enabled when the token is present in Working2==2.

Tnormal Timed transition, it is enabled when the token is present in optimize.

Taging Timed transition, it is enabled when the token is present in Pmemv and if the given time is reached.

Tafail Timed transition, it is enabled when the token is present in aging.

Thyper Timed transition, it is enabled when the token is present in migrate.

7.2 Discussion

On developing above petri net diagram in SPNP and coding in CSPL for transition of token, help us

analyze the availability value for each module. On giving the transition time for transition to happen and

transition time took in real-time implementation to move from one state to another state, based on

values in Table 7.9 MTTR and MTTF value can be calculated. From these values availability of the module

can be calculated from the formula below

Availability = MTTR ÷ (MTTR + MTTF).

Availability for all the modules are analyzed in this project and their respective availability values are

calculated on an average for 30 days Table 7.8. From the availability value of 30 days we can calculate

availability of the system for any number of years. For all token to move from one place to another,

need to pass through the transition by accepting all guard function conditions. Table 7.9 has three

parameters namely transition, and value is time for particular transition to take place and mean value

gives the value in terms of 1/hour. Mean value is used as standard format of time in analysis using SPNP

Table 7.8: Availability values of rejuvenation methods

We have considered many key parameters like aging rate, rejuvenation rate, aging rate, failure rate,

suspend rate, resume rate, restart rate etc. and assumed safety thresholds for each of modules as given

in Table 7.9. Based on these values we detect the availability of the system using Time and variable

workload policy. In all modules we just set the rejuvenation time for their safe levels at a certain interval

of time and set the threshold memory value and if aging is detected then the rejuvenation time is

optimized by ITL algorithm and on that optimized time rejuvenation occurs.

Table 7.9: Cold OS rejuvenation transition rates

Rejuvenation MethodsDays

Steady State Availability Downtime

Cold OS Rejuvenation

Warm OS Rejuvenation

Cold VM Rejuvenation

Cold VMM Rejuvenation

Warm VM Rejuvenation

VM Migration

30

30

30

30

30

30

0.998824

0.998983

0.998633

0.998846

0.998799

0.999219

0.001176

0.001017

0.001367

0.001154

0.001201

0.000781

Transition Value Mean time

OS aging rate

OS Rejuvenation rate

OS Failure rate

OS Suspend rate

OS Restart rate

VM Resume rate

VM rejuvenation rate

VM aging rate

VM failure rate

VM failure recovery rate

1 week

1 month

1 week

1 month

30 sec

15sec

1 month

1 week

1 week

1 min

0.005952381

0.001388889

0.005952381

0.001388889

120

240

0.001388889

0.005952381

0.005952381

60

Graphs are plotted based on transition rate and availability value. Graphs clearly depicts the

availability value at particular time, all graphs are plotted for thirty days interval.

All the graphs below have X-axis as availability value and Y- axis as time (1/hour). In general in

all modules, if rate of rejuvenation is high then the system will be rebooted repeatedly in short

intervals which lead to high downtime and hence availability value is low initially in all graphs

plotted.

Graph 1: OS Cold availability

In cold OS reboot process availability factor is low as system takes more time to reboot, hence we have high downtime. In this module the system is restarted normally at rejuvenation time, for this process downtime depends on the processor speed of the system, normally it might take average of one to three minutes to get back to normal working state. Availability value of this module is 0.998824 thirty days

Graph 2: OS Warm reboot

In OS warm reboot module availability value when compared to cold reboot module is high, because here complete kernel is saved as image and stored on hard disk, after reboot grub loader extract this image and kernel image will be loaded. Hence we provide no loss of data and no interruption of applications running even after reboot. Availability value of this module is 0.998983 for 30 days

Graph 3: OS Warm reboot and Cold reboot comparison

Comparison graph give us the variation of availability value in cold and warm reboot of OS, initially both

modules have same availability value due to high rejuvenation rate which have less availability value,

the graph clearly depicts warm reboot of OS has high availability compared to cold reboot of OS.

Graph 4: VM Cold reboot

In VM cold reboot, again the availability value decreases as rebooting the system takes much time and

therefore it provide the low availability to the user using the system and chances of losing the data and

request failure is high. This module has 0.998633 availability value for thirty days.

Graph 5: VMM reboot

Again this module has same fault as it was in other cold reboot processes and hence it has availability value of 0.998846 for thirty days.

Graph 6: comparison graph for VMM and VM reboot

Comparing cold reboot module of VM and VMM. We have better availability value for VMM Cold reboot module. Both module give almost same availability to the system.

Graph 7: comparison graph for OS and VM cold reboot

From the graph we clearly come to know that VM cold reboot module has better availability

value when compared to OS cold reboot module.

Graph 8: Graph for VM warm reboot

As similar to OS warm reboot, VM warm reboot as high availability compared to cold reboot modules, availability value of this module is 0.998799

Graph 9: Graph for VM migration

VM migration module has availability value of 0.999219 which is highest of all modules done in this project, in this module as no reboot and no images are saved but the complete virtual machine is migrated to another server conFigureured, hence it has no data loss and no request failure or error in running applications.

Graph 10: Graph for VM comparison

This graph gives the comparison result of all modules in VM. VM migration module has high availability and VM cold has lowest availability.

GRAPH 11: Comparison graph of all modules

This graph is main graph of our analysis, which has comparison of availability value of all modules with respect to rejuvenation time, comparing availability value of all modules clearly tell us that VM migration module has high availability and OS cold reboot module has very low availability.

7.3 Snapshots:

7.3.1 Snap shots of OS Cold Reboot

Snap shot: 1 Snap shot: 2


7.3.2 Snap shots of OS Warm Reboot

7.3.3 Snap shots of VM Cold Reboot



Snap shot: 13

7.3.4 Snap shots of VM Warm Reboot



Snap shot: 18

7.3.5 Snap shots of VM Migration




7.3.6 Snap shots of VMM Reboot



Snap shot: 29

CHAPTER 8

CONCLUSION

8.1 Conclusion

Intelligent Time and Load (ITL) balancing policy accepts time from user and optimize the

rejuvenation time whenever workload is variable, otherwise the system is rejuvenated at its

rejuvenation point. ITL policy avoids software failure and it helps to achieve high availability of

complex system. ITL policy is used in experimenting on six module namely OS Cold Reboot,

OS Warm Reboot, VM Cold Reboot, VM Warm Reboot, VM Migration and VMM Reboot.

Over the course of experiment VM Migration achieves the best study state availability as long as

VM live migration is fast enough and other server have capacity to receive the migrated VM. In

the existing policy rejuvenation is proposed based on various parameters such as hardware

failures, memory leaks, CPU utilization, request failures and so on. ITL policy considers

Physical memory as a primary factor for rejuvenation, hence it is better way to avoid

performance degradation and to increase the availability of system.

8.2 Limitations

Some important limitations are as follows:

• Project is restricted to linux platform.

• OS Warm reboot is compatibilty on Ubuntu but not with other operating systems.

• VM migration is compatible on CentOS but not with other operating systems.

• Complete(100%) availabilty is not provided in all modules.

8.3 Future Enhancement

The basic idea is to accomplish request processing on the same node in which the rejuvenation

is taking place. The combination of reboot and failover, enables a system to continue

processing requests during the reboot. Before rebooting an OS or an application running on

one node of the clustered environment, requests to the node are redirected to the other nodes of

the system. This technique improves availability of systems.

Figure 8.1 Sharing of request

Figure 8.1 describe the simultaneous execution of request processing and rejuvenation on the

same node requires an alternative request processing environment. The alternative

environment takes over processing of all requests from the original environment, and then the

rejuvenation of the original environment is started. Hence by this 100% availability can be

achieved.

REFERENCES

[1] Kishore.S.Trivedi, Sanders, W.H. Chau, “A Performability-oriented Software Rejuvenation

Framework for Distributed Applications”, IEEE Computer, Vol.24, Issue 9, 2005, pp570-

579.

[2] Kishore.S.Trivedi, Vaidyanathan.K, Goseva-Postojanova.K, “Modeling and Analysis of

Software Aging and Rejuvenation”, Proc. 33rd Annual Simulation Symposium., IEEE

Computer Society Press, Los Alamotos, CA, 2000, pp.270-279.

[3] Paulo J F, Kishor S Trivedi, Pedro Barbetta.A, “Accelerated degradation test applied to

software aging experiments” IEEE Computer, Vol 59,Issue 1, 2010, pp102-114.

[4] Letian Jiang, Guozhi Xu, Xiangyu Peng, “Time and Prediction based software rejuvenation

policy”, Information Technology and Computer Science, Kiev, 2010, pp114-117.

[5] Sachin Garg, Y.Huang, C.Kintala, Kishore.S.Trivedi, “Time and Load Based Software

Rejuvenation: Policy, Evaluation and Optimality”, Proc. 1stFault-Tolerant Symposium, 1995,

pp.22-25.

[6] Stochastic Reward Nets Model for Time based Software Rejuvenation in Virtualized

Environment Aye Myat Paing and Ni Lar Thein University of Computer Studies, Yangon

Proc. IEEE 26th Pacific International Conference. pp. 125-132, 2011.

[7] Vaidyanathan K, Kishore.S.Trivedi, “A Measurement-Based Model for Estimation of

Resource Exhaustion in Operational Software Systems”, Proc. 10th Int’l Symposium on

Software Reliability Eng., IEEE Computer Society Press, Los Alamitos, CA, 1999, pp.84-93.

[8] Sachin Garg, Puliafito, Telek, Kishore.S.Trivedi, “Analysis of Software Rejuvenation using

Markov Regenerative Stochastic Petri Net”, Proc. 6thInt’l Symposium on Software Reliability

Eng., IEEE computer Society Press, Los Alamitos, CA, 1995, pp.24-27.

[9] Virtual Machine Migration Comparison. ”VMware vSphere vs Microsoft HyperV”. A

principled technologies test report, commissioned by VMware Inc. Principled Technologies

Inc.2011.

[10] Dawei Huang, Deshi Ye, Qinming He, Jianhai Chen, and Kejiang Ye. ”VirtLM: a benchmark

for live migration of virtual machine”. In Proceedings of the 2nd ACM/SPECInternational

Conference on Performance engineering (ICPE '11). ACM, NewYork, NY, USA, 307316.

2011.

[11] Hsu-Fang Lai, Yu-Sung Wu, and Yu-Jui Cheng, “Exploiting Neighborhood Similarity for

Virtual Machine Migration over Wide-Area Network Department of Computer Science,

National Chiao Tung University, Taiwan, 2008

[12] Wenjin Hu, Andrew Hicks, Long Zhang, Eli M. Dow, “A Quantitative Study of Virtual

Machine Live Migration”, International paper of Computer Science, Department of

Computer Science, Clarkson University, Potsdam NY13699, 2008

[13] Sachin Garg, Puliafito, Telek, Kishore.S.Trivedi, “analysis of Preventive Maintenance in

Transaction Based software System”, IEEE Trans. On Computers, Vol.47, No.1, 1998,

pp.96-107.

[14] Sachin Garg, Member, Miklós Telek, and Kishor Trivedi, “Analysis of Preventive

Maintenance in Transactions Based Software Systems”, IEEE transactions on computers,

vol. 47, no. 1, Dept. of Electrical and Computer Engineering, Duke University, Durham, NC

27708, USA, JANUARY 1998

[15] Kishore S. Trivedi et al. “A Workload-Based Analysis of Software Aging, and

Rejuvenation”, IEEE transactions on reliability , Vol 54 ,No 3 , Sept 2005

[16] Salvatore Distefano, Francesco Longo, Marco Scarpa, “Availability Assessment of HA

Standby Redundant Clusters”,29th IEEE International Symposium on Reliable Distributed

System , Department di Mathematics, University of Messina, 98166 Messina, Italy, 2010

[17] Lin Huang and Qiang Xu, “Lifetime Reliability for Load-Sharing Redundant Systems with

Arbitrary Failure Distributions”, IEEE transactions on reliability, vol. 59, no. 2, JUNE 2010

[18] K.S Trivedi, G Ciardo, Dasarathy, “Achieving and assuring High availability”, International

parallel and distributed processing symposium, 2008, pp20-25

[19] Sachin Garg, A.Van Moorsel, K.Vaidyanathan, Kishore.S.Trivedi, “A Methodology for

Detection and Estimation of Software Aging”, Proc. 9th Int’l Symposium on Software

Reliability Eng., IEEE Computer Society Press, Los Alamitos, CA, 1998, pp.282-292.

[20] Dario Bruneo, Member, IEEE, Salvatore Distefano, Francesco Longo,Antonio Puliafito,

Member, IEEE, and Marco Scarpa; Workload-Based Software; Rejuvenation in Cloud

Systems; vol 62 june-2013.

[21] Pearson and Benameur, “Privacy, Security and Trust Issues Arising from Cloud

Computing,” Proc. IEEE second International Conference. Cloud Computing Technology

and Science, pp. 693-702, 2010.

[22] Ghosh, Kishore S Trivedi, Naik,V and Kim D.S , “End-to-End Per formability Analysis

for Infrastructure-as-a-Service Cloud: An Interacting Stochastic Models Approach,” Proc.

IEEE 16th Pacific Rim International Conference. Dependable Computing, pp. 125-132,

2010.

[23] Dazhi Wang a et al, “Per formability analysis of clustered systems with rejuvenation under

varying workload”, Performance evaluation 64 247–265 ,2007

[24] Andrea Bobbio and Alessandria, “PhFit: A General Phase-type Fitting Tool” Technical

report, Dept. of Telecommunications, Budapest University of Technology and Economics.

[25] Michael Grottke and Kishor S. Trivedi , “Fighting Bugs: Remove, Retry, Replicate and

Rejuvenate” Technical report , Duke University ,2010

[26] Kishor S. Trivedi “Software Rejuvenation: Modelling and Analysis” Software tool, Center

for Advanced Computing & Communication, Duke University Dhuram, NC 27708, Sept

2 2003

[27] Kishor S. Trivedi et al. “A Workload-based Analysis of Software Aging and

Rejuvenation”, Department of Computer Science, Duke University, Durham, NC 27708.

[28] Javier Alonso Rivalino Matias et al. “A Comparative Evaluation of Software Rejuvenation

Strategies”, 3rd Int. Workshop on Software Aging and Rejuvenation, Tech report, 2011.

[29] Kishor S.Trivedi et al. “Job Completion Time on a Virtualized Server Subject to Software

Aging and Rejuvenation”, 3rd International Conference, Workshop on Software Aging

and Rejuvenation, Tech report, 2011.

[30] Kishor S. Trivedi et al. “Optimizing Software Rejuvenation Policies under Interval

Reliability Criteria”, 9th International conference, on Ubiquitous Intelligence and

Computing, 9th International Conference on Autonomic and Trusted Computing, 2012.

[31] Lei Cui “Software Aging in Virtualized Environments: Detection and Prediction” IEEE

18th International conference on Parallel and Distributed Systems,

10.1109/ICPADS.2012.111, Singapore, Dec 2012

[32] Kalyanaraman Vaidyanathan and Kishor S. Trivedi, “A Measurement-Based Model for

Estimation of Resource Exhaustion in Operational Software Systems”, International paper of

Computer Science, Center for Advanced Computing & Communication, Dept. of Electrical

& Computer Engineering, Duke University Durham, NC 27708, USA,2006

[33] Aad van Moorsel, Kalyanaraman Vaidyanathan, Kishor S. Trivedi, “A Methodology for

Detection and Estimation of Software Aging”, International paper of Computer Science,

Center for Advanced Computing & Communication, Dept. of Electrical & Computer

Engineering Duke University, Durham, NC 27708, USA, 2000

[34] Michael Grottke, and Kishor S. Trivedi, “Analysis of Software Aging in a Web Server”,

IEEE transactions on reliability, VOL.55,NO. 3 September 2006

[35] Sachin Sachin Garg, Kishor S. Trivedi, “Analysis of Software Rejuvenation using Markov

Regenerative Stochastic Petri Net”, International paper of Computer Science, Center for

Advanced Comp. & Comm, Dept. of Electrical Engineering, Duke University, Durham, NC

27708, 2007

[36] Rahul Ghosh, Kishor S. Trivedi, Vijay K. Naiky, “End-to-End Performability Analysis for

Infrastructure-as-a-Service Cloud: An Interacting Stochastic Models Approach”, Pacific Rim

International Symposium on Dependable Computing, June 2009

[37] S. Distefano, A. Puliafito and M. Scarpa,” GridSPN: a Grid-based non Markovian Petri Nets

Tool" International paper of Computer Science Universit`a di Messina, Dipartimento di

Matematica Contrada Papardo, S. Sperone, 98166 Messina, Italy,2008

[38] Dazhi Wanga, Wei Xieb, Kishor S. Trivedi, “Performability analysis of clustered systems

with rejuvenation under varying workload”, International paper of Computer Science,

Department of Electrical and Computer Engineering, Duke University, Durham, NC 27708,

United States Received 27 August 2005, received in revised form 11 March 2006

[39] Andrea Bobbio DISTA, András Horváth, Miklós Telek, “PhFit: A General Phase-type

Fitting Tool”, International paper of Computer Science, Dept. of Telecommunications,

Budapest University of Technology and Economics, Hungary, 2007

[40] Siani Pearson and Azzedine Benameur, “Privacy, Security and Trust Issues Arising from

Cloud Computing”, 2nd IEEE International Conference on Cloud Computing Technology

and Science, Cloud and Security Research Lab, HP Labs Bristol, UK, 2005

[41] Arash Rezaei, Mohsen Sharifi, “Rejuvenating High Available Virtualized Systems”,

International Conference on Availability, Reliability and Security School of Computer

Engineering, Iran University of Science and Technology Tehran, Iran, 2010

[42] Luiz F. Bittencourt, Carlos R. Senna and Edmundo R. M. Madeira, “Scheduling Service

Workflows for Cost Optimization in Hybrid Clouds”, International paper of Computer

Science, Institute of Computing - University of Campinas (UNICAMP),P.O. Box 6196,

Campinas, São Paulo, Brazil, 2008

[43] Yennun Huang and Chandra Kintala, “Software Rejuvenation: Analysis, Module and

Applications”, IEEE 12th International Symposium on High Assurance Systems

Engineering, AT&T Bell Laboratories Murray Hill, NJ 07974 Nick Kolettis and N. Dudley

F’ulton, AT&T Bell Laboratories Middletown, NJ 07748, 2010

[44] Salvatore Distefano, Francesco Longo, Marco Scarpa, “Symbolic Representation Techniques

in Dynamic Reliability Evaluation”, IEEE 12th International Symposium on High Assurance

Systems Engineering, Dipartimento di Matematica, Università di Messina Contrada di Dio,

S. Agata, 98166 Messina, Italia, 2010

[45] Luis Moura Silva1, Javier Alonso2, Paulo Silva, “Using Virtualization to Improve Software

Rejuvenation”, International paper of Computer Science, CISUC, Univ. of Coimbra,

Portugal BSC-UPC, Barcelona, Spain, 2009

[46] Zaipeng Xie, Hongyu Sun and Kewal Saluja, “A SURVEY OF SOFTWARE FAULT

TOLERANCE TECHNIQUES”, International paper of Computer Science, University of

isconsin-Madison/Department of Electrical and Computer Engineering 1415 Engineering

Drive, Madison WI 53706 USA, 2009

[47] Domenico Cotroneo, Roberto Natella, Roberto Pietrantuono, “A Survey of Software Aging

and Rejuvenation Studies”, International paper of Computer Science Università degli Studi di

Napoli Federico II, 2011

[48] Ms.N.M.Hemadevi, Ms. M.Dhivya, Mr.K.Manikandan, “A Survey on Software Aging and

Rejuvenation in Server Virtualized System”, ISSN: 2278 – 7798, International Journal of

Science, Engineering and Technology Research (IJSETR) Volume 2, Issue 11, November

2013

[49] Domenico Cotroneo, Roberto Natella, Roberto Pietrantuono, “Software Aging and

Rejuvenation: Where we are and where we are going International paper of Computer

Science”, Dipartimento di Informatica e Sistemistica Universit`a degli Studi di Napoli

Federico II Via Claudio 21, 80125, Naples, Italy, 2010

[50] Yun Liu y, Yue Ma z, James J. Han z, “Modeling and Analysis of Software Rejuvenation in

Cable Modem Termination System”, International paper of Computer Science, Department

of ECE, Duke University, Durham, NC 27708, 2010

[51] Rean Griffith, Gail Kaiser, Javier Alonso L´opez, “Multi-perspective Evaluation of Self-

Healing Systems using Simple Probabilistic Models”, International paper of Computer

Science, Columbia University, 2011

[52] Jean Araujo, Rubens Matos, Paulo Maciel, “Software Rejuvenation in Eucalyptus Cloud

Computing Infrastructure: a Method Based on Time Series Forecasting and Multiple

Thresholds” Third International Workshop on Software Aging and Rejuvenation, Informatics

Center, Federal University of Pernambuco, Recife, Brazil,

APPENDIX

Test cases

OS COLD REBOOT

Table 5.19: Testing whether system is checking current system Time

Table 5.20: Testing whether system is checking current system free memory

Test Case ID T-19

Purpose Testing whether system is checking current system Time



Expected Output System should checkthe current system time

Post-Conditions Display current system time

Execution History


Test Case ID T-20

Purpose Testing whether system is checking current system free memory



Expected Output System should check the current system free memory

Post-Conditions Display current system free memory

Execution History


Table 5.21: Testing whether system is optimizing the rejuvenation time

Test Case ID T-21

Purpose Testing whether system is optimizing the rejuvenation time

Pre-Conditions System Time and System Free memory

Inputs Time to Rejuvenation and Memory threshold value

Expected Output System should optimize Rejuvenation time

Post-Conditions Reboot the system when current time is equal to rejuvenation time

Execution History


Table 5.22: Testing whether system is rebooting when system time is equal to the Time to Rejuvenate (TTR)

Test Case ID T-22

PurposeTesting whether system is rebooting when system time is equal to the Time to

Rejuvenate(TTR)

Pre-Conditions System Time

Inputs Time to Rejuvenation

Expected Output System should reboot when free memory is equal to the threshold value

Post-Conditions After rebooting system should not save the status of the OS

Execution History


Table 5.23: Testing whether system is rebooting when system free memory is equal to the Threshold value

Test Case ID T-23

PurposeTesting whether system is rebooting when system Free memory is equal to the

Threshold value



Expected Output System should reboot when current time is equal to the rejuvenation time

Post-Conditions After rebooting system should not save the status of the OS

Execution History

Date Result Version Remark17-02-2014 Pass 1.0 Testing passed in Ubuntu 12.04 operating system

15-03-2014 Pass 1.0 Testing passed in CentOS operating system27-03-2014 Pass 1.0 Testing passed in Ubuntu 12.04 operating system04-04-2014 Pass 1.0 Testing passed in CentOS operating system09-04-2014 Pass 1.0 Testing passed in Ubuntu 12.04 operating system09-04-2014 Pass 1.0 Testing passed in CentOS operating system

OS WARM REBOOT



Test Case ID T-24






Execution History




Test Case ID T-25






Execution History





Test Case ID T-26






Execution History




Table 5.27: Testing whether system capturing the image of current state of an OS

Test Case ID T-27

PurposeTesting whether the system capturing the image of current running state of an

Operating System(OS)

Pre-Conditions System should be in working condition

Inputs Running an algorithm

Expected Output System should capture the image of current state of an Operating System(OS)

Post-Conditions System capture the image of current state of an Operating System(OS

Execution History



Table 5.28: Testing whether system capturing the image of current state of an OS

Test Case ID T-28

PurposeTesting whether the system capturing the current running state of an Operating

System(OS)

Pre-Conditions System should be in working condition


Expected Output System should capture the image of current state of an Operating System(OS)

Post-Conditions System capture the image of current state of an Operating System(OS

Execution History

Date Result Version Remark28-03-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0427-03-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0404-04-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0409-04-2014 Pass 1.0.1 Testing passed in Ubuntu 12.0409-04-2014 Pass 1.0.1 Testing passed in Ubuntu 12.04

Table 5.29: Testing whether system capturing the image of current state of an OS in a specified path

Test Case ID T-29


Operating System(OS) at an specified path

Pre-Conditions Specify the Path


Expected Output System should store the image at an specified path

Post-Conditions System stores the image at an specified path

Execution History



Table 5.30: Testing whether system capturing the image of current state of an OS in a specified path

Test Case ID T-30


Operating System(OS) at an specified path

Pre-Conditions Specify the Path




Execution History


Table 5.31: Testing whether the system is rebooting after capturing image

Test Case ID T-31

Purpose Testing whether the system is rebooting after capturing image

Pre-Conditions System should be in running


Expected Output System should reboot after capturing image

Post-Conditions System reboot after capturing image

Execution History



Table 5.32: Testing whether the system is rebooting after capturing image

Test Case ID T-32

Purpose Testing whether the system is rebooting after capturing image

Pre-Conditions System should be in running


Expected Output System should reboot after capturing image

Post-Conditions System reboot after capturing image

Execution History


Table 5.33: Testing whether the system is loading the image after reboot

Test Case ID T-33

Purpose Testing whether the system is loading the image after reboot

Pre-Conditions System should restart automatically


Expected Output System should load image after reboot

Post-Conditions System loads an image after reboot

Execution History



Table 5.34: Testing whether the system is loading the image after reboot

Test Case ID T-34

Purpose Testing whether the system is loading the image after reboot



Expected Output System should load image after reboot

Post-Conditions System loads an image after reboot

Execution History


Table 5.35: Testing whether System is in same status after reboot

Test Case ID T-35

Purpose Testing whether System is in same status after reboot



Expected Output System should be in same status after reboot

Post-Conditions System will be in same status after reboot

Execution History



Table 5.36: Testing whether System is in same status after reboot

Test Case ID T-36

Purpose Testing whether System is in same status after reboot



Expected Output System should be in same status after reboot

Post-Conditions System will be in same status after reboot

Execution History


VM COLD REBOOT


Test Case ID T-37






Execution History



Test Case ID T-38






Execution History



Test Case ID T-39






Execution History


Table 5.40: Testing whether VM is rebooting when system time is equal to the Time to Rejuvenate (TTR)

Test Case ID T-40

PurposeTesting whether VM is rebooting when system time is equal to the Time to

Rejuvenate(TTR)

Pre-Conditions Virtual Machine(VM) should be in running state

Inputs Time to Rejuvenation

Expected Output

Virtual Machine(VM) should reboot when current time is equal to the rejuvenation time

Post-Conditions Reboot the VM when free memory is equal to Rejuvenation Time

Execution History


Table 5.41: Testing whether VM is rebooting when system free memory is equal to the Threshold value

Test Case ID T-41

PurposeTesting whether VM is rebooting when system Free memory is equal to the

Threshold value

Pre-Conditions Virtual Machine(VM) should be in running state


Expected Output

Virtual Machine(VM) should reboot when free memory is equal to the threshold value

Post-Conditions Reboot the VM when free memory is equal to threshold value

Execution History


VM WARM REBOOT



Test Case ID T-42






Execution History


Test Case ID T-43






Execution History



Test Case ID T-44






Execution History


Table 5.45: Testing whether the system capturing the image of current running state of an Operating System (OS) in a Virtual Machine (VM)

Test Case ID T-45

Purpose Testing whether the system capturing the image of current running state of an

Operating System(OS) in an Virtual Machine(VM)

Pre-Conditions VM should be running state

Inputs Running our algorithm

Expected Output

System should capture the image of current state of an Operating System(OS) running in Virtual Machine(VM)

Post-Conditions

System capture the image of current state of an Operating System(OS) running on Virtual Machine(VM)

Execution History


Table 5.46: Testing whether the system capturing the image of current running state of an Operating System

(OS) in a Virtual Machine (VM) at a specified path

Test Case ID T-46

Purpose Testing whether the system capturing the image of current running state of an

Operating System(OS) in an Virtual Machine(VM) at an specified path





Execution History


Table 5.47: Testing whether the Virtual Machine (VM) is rebooting after capturing image

Test Case ID T-47

Purpose Testing whether the Virtual Machine(VM) is rebooting after capturing image



Expected Output Virtual Machine(VM) should reboot after capturing image

Post-Conditions Virtual Machine(VM) reboot after capturing image

Execution History


Table 5.48: Testing whether the Virtual Machine (VM) is loading the image after reboot

Test Case ID T-48

Purpose Testing whether the Virtual Machine(VM) is loading the image after reboot



Expected Output Virtual Machine(VM) should load image after reboot

Post-Conditions Virtual Machine(VM) load an image after reboot

Execution History


Table 5.49: Testing whether the Virtual Machine (VM) is in same status after reboot

Test Case ID T-49

Purpose Testing whether the Virtual Machine(VM) is in same status after reboot



Expected Output Virtual Machine(VM) should be in same status after reboot

Post-Conditions Virtual Machine(VM) will be in same status after reboot

Execution History


VM MIGRATION

Table 5.50: Testing whether both Physical machine (PM) have same configuration

Test Case ID T-50

Purpose Testing whether both Physical machine(PM) have same configuration

Pre-Conditions Two physical machine we should have

Inputs -

Expected Output Both system should have same configuration

Post-Conditions Both system have same configuration

Execution History


Table 5.51: Testing whether the VM is migrating from one Physical machine (PM) to another Physical machine (PM) based on time

Test Case ID T-51

PurposeTesting whether the VM is migrating from one Physical machine(PM) to another

Physical machine(PM) based on time


Inputs Time

Expected Output

VM should migrate from one Physical machine(PM) to another Physical machine(PM) at a given time

Post-Conditions

VM migrates from one Physical machine(PM) to another Physical machine(PM) at a given time

Execution History





Table 5.52: Testing whether the VM is migrating from one Physical machine (PM) to another Physical machine (PM) based on workload

Test Case ID T-52


Physical machine(PM) based on workload


Inputs Threshold value

Expected Output

VM should migrate from one Physical machine(PM) to another Physical machine(PM) at a given Threshold value

Post-Conditions

VM migrates from one Physical machine(PM) to another Physical machine(PM) at a given Threshold value

Execution History





Table 5.53: Testing whether the VM is migrating from one Physical machine (PM) to another Physical

machine (PM) based on time and workload

Test Case ID T-53


Physical machine(PM) based on time and workload


Inputs Time and Threshold value

Expected Output

System should optimize Rejuvenation time at an optimized time VM should migrate from one Physical machine(PM) to another Physical machine(PM)

Post-Conditions

VM migrates from one Physical machine(PM) to another Physical machine(PM) at an optimized time

Execution History





Table 5.54: Testing whether after migration same stats will continue

Test Case ID T-54

Purpose Testing whether after migration same stats will continue



Expected Output Same status should continue

Post-Conditions Same status will continue

Execution History





Table 5.55: Testing whether after migration same stats will continue

Test Case ID T-55

Purpose Testing whether after migration same stats will continue



Expected Output Same status should continue

Post-Conditions Same status will continue

Execution History

Date Result Version Remark30-03-2014 Pass 1.0.1 Testing passed in CentOS operating system04-04-2014 Pass 1.0.1 Testing passed in CentOS operating system09-04-2014 Pass 1.0.1 Testing passed in CentOS operating system

Table 5.56: Testing whether after migration physiclemachine1 (PM1) is rebooting

Test Case ID T-56

Purpose Testing whether after migration PhysicleMachine1 (PM1) is rebooting



Expected Output PhysicleMachine1 (PM1) should reboot

Post-Conditions PhysicleMachine1 (PM1) will reboot

Execution History





Table 5.57: Testing whether after migration PhysicleMachine1 (PM1) is rebooting

Test Case ID T-57

Purpose Testing whether after migration PhysicleMachine1 (PM1) is rebooting



Expected Output PhysicleMachine1 (PM1) should reboot

Post-Conditions PhysicleMachine1 (PM1) will reboot

Execution History

Date Result Version Remark30-03-2014 Pass 1.0.1 Testing passed in CentOS operating system04-04-2014 Pass 1.0.1 Testing passed in CentOS operating system09-04-2014 Pass 1.0.1 Testing passed in CentOS operating system

VMM REBOOT

Table 5.58: Testing whether before rebooting VMM all the VM's are going to shut down or not

Test Case ID T-58

PurposeTesting Whether before rebooting VMM all the VM's are going to shut down or

not

Pre-Conditions VM’s should be in running state


Expected Output ALL the VM's should shutdown

Post-Conditions All VM's will shutdown

Execution History


Table 5.59: Testing whether the connection between VMM and VM'S are closing

Test Case ID T-59

Purpose Testing whether the connection between VMM and VM'S areclosing

Pre-Conditions VM’s should be in running state


Expected Output Connection should be closed

Post-Conditions Connection will close

Execution History


software rejuvenation

Education