# Modeling and Evaluation of Power-Aware Software Rejuvenation in Cloud Systems
## 4 System Description  
Figure 1 shows the structure of an IaaS cloud system where user requests are expressed as requests for VMs. This system contains \(N\) physical machines, each one with an active VMM. User requests are placed in the input queue upon arrival. The migration queue is used when VMs need to be migrated between VMMs.  
Right after system startup, all PMs of the cloud data center are assumed to be switched-off and they are switched on only on demand after receiving requests for VMs. Since active PMs consume more power, as long as there is free capacity on active VMMs, no PM is switched on. In other words, a new PM is switched on only if none of the active VMMs have sufficient capacity to accept migrating or requested VMs. When there is a VM request in the input queue, one of the active VMMs with free capacity is randomly selected to service the request. Similarly, when there is a VM in the migration queue, one of the active VMMs with free capacity is randomly chosen to service the migrating VM. We supposed that a PM can host up to \(M\) VMs concurrently. After finishing the t  
Figure 1: The structure of the Infrastructure-as-a-Service (IaaS) cloud system under study.  
the resources assigned to that VM are returned to their corresponding VMM, thereby providing the VMM some capacity to accept another VM. In order to make the model more realistic, we assumed that the system is able to handle two different types of VMs: big and small VMs. Big VMs are VMs that have a greater impact on VMM aging due to having a longer runtime or equivalently, using a more significant share of system resources. Here, we assumed that a big VM has a runtime twice as large as the runtime of a small VM.  
A VMM may fail due to different reasons. One of the notable causes of VMM failure is aging-related errors. If an aged VMM is not rejuvenated at in time, the VMM fails. Thus, the failure of all VMs running on top of that VMM is possible. In serving a VM, the age of its hosting VMM increases, but completion of that VM does not decrease the VMM's age. This is because running a VM has some adverse effects on the corresponding VMM that are not removed once VM's tasks are completed. Therefore, both the number and the type of VMs served by a VMM can be considered indicators of its age. By VMM age, we mean the cumulative workloads that are accepted and served by that VMM after its last reboot. In our considered system, once the age of a VMM reaches the maximum threshold \(F\), regardless of there being free capacity on other VMMs, the active VMs of that VMM are put in the migration queue, and the VMM is then rejuvenated. In order to improve system reliability, when the age of a VMM reaches the threshold \(F^{\prime}\) (\(F^{\prime}<F\)), and if other VMMs have enough free capacity to accept the VMs running on that VMM, these VMs are put in the migration queue, and the aged VMM is rejuvenated before reaching the threshold \(F\). With the aim of power saving, when a VMM is relatively idle and other VMMs can serve its active VMs, these VMs are put in the migration queue to be migrated to those VMMs, and the emptied PM is switched off.