Energy-Aware Live VM Migration Using Ballooning in Cloud Data Center

Abstract

The demand for digitization has inspired organizations to move towards cloud computing, which has increased the challenge for cloud service providers to provide quality service. One of the challenges is energy consumption, which can shoot up the cost of using computing resources and has raised the carbon footprint in the atmosphere; therefore, it is an issue that it is imperative to address. Virtualization, bin-packing, and live VM migration techniques are the key resolvers that have been found to be efficacious in presenting sound solutions. Thus, in this paper, a new live VM migration algorithm, live migration with efficient ballooning (LMEB), is proposed; LMEB focuses on decreasing the size of the data that need to be shifted from the source to the destination server so that the total energy consumption of migration can be reduced. A simulation was performed with a specific configuration of virtual machines and servers, and the results proved that the proposed algorithm could trim down energy usage by 18%, migration time by 20%, and downtime by 20% in comparison with the existing approach of live migration with ballooning (LMB).

1. Introduction

Cloud computing is trending among customers due to the tremendous advantages that it offers at very low rates [1]. Due to an increase in the number of customers, energy consumption has increased the expenditure of cloud service providers, thus increasing the burden on the pockets of customers. The primary solution for reducing energy usage is virtualization, which provides multiple virtual instances on limited physical machines/servers [2]. The request coming from the client is mapped on these virtual machines that are allocated on the available physical machines. After the allocation of all VMs to the servers, sometimes, there is a need to transfer the virtual machine from one server to another, which comes with the overhead of migration associated with components, which increases energy consumption. The reason for this shifting can be a failure in the server or VM, the overutilization of any server, etc. VM migration is depicted in Figure 1.

Figure 1. VM migration scenario of over-utilized and under-utilized servers.

VM migration [3] is primarily of two types—(1) offline migration (service is halted for the complete migration time), and (2) online/live migration (service is halted during the time in which the VM gets transferred from source to destination, but the shifting of memory and storage state is performed in “power ON” mode). Among the two types, live VM migration fits the current scenario, as a customer cannot accept extended downtime of service.

Techniques used in memory data migration [4] are the following:

• Pre-copy—Firstly, the data are transferred while the VM serves the customer. After a certain point, the VM is turned off and transferred to the destination host/server.
• Post-copy—Firstly, the VM is turned off and transferred to the destination host/server. Then, the data are transferred while the VM serves the customer.
• Hybrid—Data are transferred both before and after the shifting of the VM.

Techniques used in storage data migration [4] are the following:

• Pre-copy—Disk blocks are transferred before memory pages.
• Post-copy—Disk blocks are transferred after memory pages.
• Hybrid—Disk blocks and memory pages are transferred simultaneously.

The energy used in one live migration should be optimized so that total energy of the data center can be controlled. The goal of our research was to minimize the energy of migration by reducing the migration time and downtime. The parameters that have significant importance in live VM migration were considered and evaluated as follows:

• Energy consumption—The overall energy usage in the cloud data centers can raise the cost to customers. Virtualization and live VM migration are the primary steps in this regard. Live VM migration, if performed frequently, can affect the system in the reverse direction.
• Migration time—It defines the time between the initiation of VM migration and the resumption of the VM on the destination server.
• Downtime—It is the time when the VM remains halted so that it can be finally shifted to the destination server.
• Resource utilization—It is the measurement of the server that indicates how efficiently the server is used in the data center.
• Makespan—It is the measurement of the server regarding the working time, that is, the submission of the first VM till the completion of the last VM.
• Atomicity—It is the property whereby migration is completed successfully without disturbing other VMs.
• Convergence—It is the point in time when the difference in the memory and storage state between the source and the destination server is almost nil. This signifies a successful copy of data.

The contribution of the paper in terms of the above-mentioned parameters is that the new proposed algorithm can reduce energy consumption, downtime, and migration time and can improve resource utilization significantly. The structure of the paper is as follows: Section 2 represents a thorough survey on existing live migration techniques. Section 3 presents the framework, flowchart, and algorithm form of the proposed approaches. Section 4 presents the experimental testbed for validating the proposed algorithm and its comparison with the existing algorithm. Section 5 illustrates the results and their discussion, showing a comparative detailed analysis of the existing and proposed approaches. Section 6 discusses the workflow of a cloud data center after incorporating the proposed algorithm. Finally, Section 7 presents the concluding remarks.

2. Related Work

The authors in [5] combined pre-paging with the post-copy technique of migration through dynamic self-ballooning implemented in Xen. The methodology reduced the network load by 21%. DSB releases free pages from the VM to the hypervisor regularly, considerably speeding up migration with minimal performance damage. The authors in [6] proposed the migration approach “Migration with Data Deduplication (MDD)”, which uses data deduplication to increase the performance of migration. The proposed approach is able to minimize the data (memory and storage) transferred, migration time, and downtime. The authors of [7] reported live VM migration in VMware ESX with three approaches to storage migration, i.e., “Snapshotting (in ESX 3.5), Dirty block tracking (in ESX 4.0/4.1) and IO Mirroring (in ESX 5.0)”.

The authors of [8] proposed “Server consolidation algorithm-Sercon”, which can minimize the count of working servers as well as the count of VM migrations as compared with the “first-fit decreasing algorithm”; an experiment was performed on the .NET framework. The authors of [9] proposed two algorithms: “VM placement Optimization”, which finds overloaded and underloaded hosts, and “Power Aware Best Fit Decreasing (PABFD)”, which reduces the energy consumption in the migration process. The authors of [10] worked on reducing the power required for live VM migration and proposed two “power-capping” schemes for reducing sudden power shooting during migration. The authors of [11] proposed the “memory-compression-based VM migration approach (MECOM)” approach, which uses a memory compression technique to improve VM migration and was found to be effective in reducing migration time, downtime, and the data to be transferred.

The authors of [12] introduced ballooning to manage the memory on a server by deleting unused memory pages from time to time. They also proposed a “skewness” algorithm for load balancing. The authors of [13] proposed “introspection-based memory pruning” to improve live migration by minimizing unnecessary pages. This procedure reduces network traffic and migration time. The authors of [14] proposed the storage migration approach “LayerMover” using the data deduplication method for optimization. It was proved to be better than the previously used data deduplication approach. The authors of [15] proposed a “memory prediction technique” that chooses pages to migrate based on the dirty rate of the pages. In the proposed technique, the total migration time is reduced, but the downtime is not affected.

The authors of [16] discussed memory optimization techniques—“Virtual Swap Management Mechanism (VSMM) “, “ESX by VMware”, “Transparent Page Sharing (TPS)”, and “Database Optimization” and “Ballooning”—and their merits. The authors of [17] proposed the “Least recently used (LRU) stack distance-based delta compression” algorithm for effective live migration using the compression and prediction technique. The authors of [18] suggested strategies for multiple VM migrations such as “improved serial migration strategy” and “m mixed migration strategy”. They also introduced queuing models such as “M/M/C/C” and “M/M/C” to measure the output. The authors of [19] presented a survey of all existing live VM migration techniques and discussed the objectives, base techniques, advantages, and performance metrics of VM migration. The authors of [20] introduced the concept of ballooning in live migration and showed the improvement of the maximum and minimum migration time.

The authors of [21] tested the working of migration in openstack in a situation of high system constraints and network issues. They performed a performance analysis of migration, which could help researchers to find better optimization methods. The authors of [22] presented a survey of existing live migration techniques, along with the name of the hypervisor, performance parameters, and basic technique (pre-copy, post-copy, and hybrid) used, and pros and cons, if any. The authors of [23] presented a taxonomy of live VM migration, which provides details of “planning and scheduling algorithms”, “performance and cost models”, “migration generation in resource management rules”, “management lifecycle and orchestration”, and “assessment methodologies”. The paper also mentioned and reviewed the current state of “migration scheduling types”, “migration network awareness”, “scheduling scope”, “heterogeneous and homogeneous solutions”, and “scheduling objectives”. The authors of [24] proposed a security-based technique called “VMshield”, which can protect virtual machines from outside attacks, and found that it can provide more security with less storage requirement than existing security methods. The author of [25] proposed a VM consolidation technique that is based on the “Ant Colony Optimization” method to provide a better VM placement technique. The authors of [26] proposed a “BoT scheduling algorithm” to maximize the profit of cloud service providers using the user-specified deadline for each request.

The authors of [27] proposed a game approach to VM migration for multi-tier software in the IaaS model and its fault detection technique. The authors of [28] proposed a resource management algorithm named “RU-VMM” using a VM migration technique. The paper also considered successful and dropped migration for calculating the threshold for resource utilization. The authors of [29] proposed a VM migration algorithm named “V2PQL” based on the Markov decision technique while maintaining the values of resource utilization and load balancing. Load balancing is defined as

$${\sigma }_j=\sqrt{\frac{1}{m}\sum _{i=1}^m\left(\frac{e_j^{\left(i\right)}}{e_j}-1\right)}$$

(1)

Moreover, resource utilization is defined as

$$H^{\left(i\right)}=\sqrt{\sum _{j=1}^k\left(\frac{u_j^{\left(i\right)}}{u^{\left(i\right)}}-1\right)}$$

(2)

The authors of [30] worked on minimizing total migration time and proposed three algorithms—“Host Selection Migration Time (HSMT), VM Reallocation Migration Time (VMRMT), and VM Reallocation Bandwidth Usage (VMRBU)”. The proposed algorithms decreased the migration time by a maximum of 50%, which can be calculated as

$$\mathrm{Total} \mathrm{time} \mathrm{consumed}=\propto \times A\left(\mathrm{HSMT}\right)+\beta \times B\left(\mathrm{VMRMT}\right)+\gamma \times C\left(\mathrm{VMRBU}\right)$$

(3)

The authors of [31] proposed “Enhanced artificial bee colony (PEA)” for a better migration of virtual machines in two phases. The total migrations were also reduced by 25%. The achieved energy reduction was 13%.

The next section presents the proposed algorithm and comparisons with the existing algorithm.

3. Proposed Algorithm

After an intense literature survey, many techniques were studied that can make live VM migration more energy efficient. One of the techniques is ballooning, which is a procedure used to delete unused data before migrating the virtual machine. It saves more time than other techniques, as it directly decreases the data that need to be transferred. It is achieved by checking the number of accesses made to the data (memory page or disk block) during the execution of the virtual machine, and all the data with low values are considered target data for deletion.

The steps of the existing ballooning algorithm [19] for live VM migration are the following:

• Before migration, execute ballooning, which is the process to delete unused data (memory pages and storage disk blocks) from the VM storage.
• Pre-copy to migrate the current state of memory pages and storage disk blocks.
• Power off the VM, transfer it to the target server, and restart.
• Post-copy to migrate the memory pages and disk blocks left.
• Calculate the migration time and downtime.

The drawback of the algorithm is that ballooning is not able to differentiate between a page created long ago having the least number of accesses and a page which has just been created and has zero accesses. Hence, in the proposed algorithm, the time for the generation of each data is also taken into account, so that just-created data that can be of significant importance are not considered unused.

The novelty of the proposed algorithm consists in the following:

• Ballooning is combined with the least recently used (LRU) page replacement technique.
• The pre-copy step is discarded to reduce the transmission time.
• The setup of the VM at the destination is performed parallelly with ballooning to save time by sending the configuration details of the VM from the source to the destination server beforehand.

The list of abbreviations mentioned in the algorithms is shown in Table 1.

Table 1. Abbreviation list.

Abbreviation	Definition
CPUi	CPU capacity of server and VM
POWi	Power capacity of server
TIMEi	Execution time of VM
UTILi	Utilization factor of server
SR	Source server for VM migration
DS	Destination server for VM migration
Num_Pagess	Number of memory pages used by VM selected for migration
Num_Blockss	Number of disk blocks used by VM selected for migration
Transt	Total time needed to transfer memory page or disk block from one server to the other
St	Time between halt of VM at source and resumption at destination server
Sett	Time required to set up VM at destination
TMT	Total migration time
P (F,t) [31]	Power capacity of the ith server in terms of function of placement ”F”
Ui(F,t) [31]	Utilization factor of the ith server in terms of placement ”F2 and time ”t”
Resutili [32]	Resource utilization of the ith server
Makespan [32]	Time from submission of the 1st VM to completion of the last VM
CPU_utili	Utilized CPU value on the ith server
Tvmj	Execution time of VM j
Tvm_maxi	Maximum time of any VM on server i

The existing and proposed algorithms are explained below:

• Live migration with ballooning (LMB)—As presented in Algorithm 1, initially the waiting VMs are allotted to the available server. If the server is overburdened, then a decision is taken to migrate the minimum-CPU-capacity VM from it to some other server that has sufficient space. Firstly, ballooning is performed to delete unused pages. Then, the migration of memory and disk storage state is performed in the pre-copy stage. After copying the data, the VM is turned off at the source server and resumed at the destination after setting up the configuration. The next step is again the migration of memory and storage state in the post-copy stage. Once the migration is over, energy consumption, total migration time, and downtime are computed. When no VMs are left, resource utilization and makespan are calculated. The framework is shown in Figure 2, and the flowchart is shown in Figure 3.
  

  Figure 2. LMB framework.
  

  Figure 3. LMB flowchart.

• Live migration with efficient ballooning (LMEB)—As presented in Algorithm 2, firstly, the waiting VMs are allotted to the available server. If the server is overburdened, then a decision is taken to migrate the minimum-CPU-capacity VM from it to some other server that has sufficient space. Firstly, ballooning is performed to delete unused pages and disk blocks considering the time of generation to use the LRU (least recently used) technique. Then, the VM is turned off at the source server and resumed at the destination after setting up the configuration. The next step is the migration of memory and storage state in the post-copy stage. Once the migration is over, energy consumption, total migration time, and downtime are calculated. If there are no VMs left waiting, resource utilization and makespan are computed. The framework is shown in Figure 4, and the flowchart is shown in Figure 5.
  

  Figure 4. LMEB framework.
  

  Figure 5. LMEB flowchart.

Algorithm 1. Live migration with ballooning (LMB)

Input CPUi and POWi of N (i = 1 to N) servers. Input CPUj and TIMEj of M (j = 1 to M) VMs. Initiate allocation of VMs on the servers using DEE_BFD [33]. Calculate UTILi of N servers. If UTILi = 0.90 to 1.00 then SR = Serveri If UTILi = 0.20 to 0.50 then DS = Serveri Select the minimum CPUj VM from SR. Num_Pagess and Num_Blockss = Random Number between 10 to 20. Generate 1-d arrays—Memory [] and Blocks [] randomly with size Num_Pagess and Num_Blockss respectively where is index value = number of accesses Perform ballooning by removing value ‘0′ from two arrays. Assume: Transt = 10 s 1 s Transt consumes 10 kWh power St = 10 s Sett = 5 s Perform Pre-copy technique TMT = (Num_Pagess + Num_Blockss) * Transt. Stop the VM on source and resume it on destination after completing the setup procedure. Generate Memory [] and Blocks [] again for remaining accessed memory pages and disk blocks. Perform Post-copy technique TMT = TMT + (Num_Pagess + Num_Blockss) * Transt. Calculate final TMT, TMT = TMT +St + Sett Calculate downtime DT = St + Sett Calculate energy consumption [31] Pi(F,t)= 0.7 * Pi + (0.3 * Pi * Ui(F,t)) for ith server Ui(F,t) = (CPU_utili)/(CPUi) Calculate resource utilization and makespan [32] Res_util = Res_utili for i = 1 to N, where $\mathrm{Res}\_{\mathrm{util}}_{\mathrm{i}}=(\sum _{j=1}^{m}Tv{m}_j$)/(makespan * M) and makespan = $\sum _{j=1}^{R}Tvm\_ma{x}_j$

Algorithm 2. Live migration with efficient ballooning (LMEB)

Input CPUi and POWi of N (i = 1 to N) servers. Input CPUj and TIMEj of M (j = 1 to M) VMs. Initiate allocation of VMs on the servers using DEE_BFD [33]. Calculate UTILi of N servers. If UTILi = 0.90 to 1.00 then SR = Serveri If UTILi = 0.20 to 0.50 then DS = Serveri Select the minimum CPUj VM from SR. Num_Pagess and Num_Blockss = Random Number between 10 to 20. Generate 2-d arrays—Memory [][2] and Blocks [][2] randomly with row size Num_Pagess and Num_Blockss respectively where 1st column = number of accesses and 2nd column = time of generation. Perform ballooning on source server by removing value ‘0′ from two arrays considering the time of generation and set up of VM on the destination server. Assume: Transt = 10 s 1 s Transt consumes 10 kWh power St= 10 s Stop the VM on the source and resume it on destination. Perform Post-copy technique TMT = (Num_Pagess + Num_Blockss) * Transt. Calculate final TMT, TMT = TMT +St Calculate downtime DT = St Calculate energy consumption [31] Pi(F,t)= 0.7 *Pi + (0.3 * Pi * Ui(F,t)) for ith server Ui(F,t) = (CPU_utili)/(CPUi) Calculate resource utilization and makespan [32] Res_util = Res_utili for i = 1 to N, where ${\mathrm{Res}\_\mathrm{util}}_{\mathrm{i}}=(\sum _{j=1}^{m}Tv{m}_j$)/(makespan * M) and Makespan = $\sum _{j=1}^{R}Tvm\_ma{x}_j$

The next section discusses the comparative analysis of the algorithms in terms of parameters.

4. Experimental Testbed

Simulation was performed in JAVA using the in-built classes to store the mapping of virtual machines to the server. Different scenarios were considered to check the validity of the proposed algorithm. These scenarios have the same number of servers, s_i {i = 1, 2, 3, 4, 5}, and their configuration, c_i {i = CPU, Power} but different numbers of virtual machines, v_i {i = 1, 2, 3}, {i = 1, 2, 3, 4}, {i = 1, 2, 3, 4, 5},{ i = 1, 2, 3, 4, 5, 6}, {i = 1, 2, 3, 4, 5, 6, 7} and different configurations, c1_i {i = CPU, Time}. The five scenarios were taken, and each scenario witnessed an incremental increase in the number of virtual machines. The configuration details of the server included CPU capacity in instructions per cycle and power capacity in kwh. The configuration details of the virtual machines included CPU capacity in instructions per cycle and execution time in seconds. The server configuration (CPU and power capacity) is presented in Table 2.

Table 2. Server configuration.

Server No.	1	2	3	4	5
CPU capacity (instruction cycles)	2500	2000	1500	3000	2700
Power capacity (kWh)	300	200	450	350	500

The virtual machine configurations (CPU and execution duration) in these five scenarios are presented in Table 3, Table 4, Table 5, Table 6 and Table 7.

Table 3. Configuration of 3 virtual machines for scenario 1.

Virtual Machine No.	1	2	3
CPU capacity (instruction cycles)	1200	800	1000
Execution time (seconds)	30	50	40

Table 4. Configuration of 4 virtual machines for scenario 2.

Virtual Machine No.	1	2	3	4
CPU capacity (instruction cycles)	1200	800	1000	2000
Execution time (seconds)	30	50	40	20

Table 5. Configuration of 5 virtual machines for scenario 3.

Virtual Machine No.	1	2	3	4	5
CPU capacity (instruction cycles)	1200	800	1000	1300	700
Execution time (seconds)	30	50	40	20	90

Table 6. Configuration of 6 virtual machines for scenario 4.

Virtual Machine No.	1	2	3	4	5	6
CPU capacity (instruction cycles)	1200	800	1000	1300	700	600
Execution time (seconds)	30	50	40	20	90	40

Table 7. Configuration of 7 virtual machines for scenario 5.

Virtual Machine No.	1	2	3	4	5	6	7
CPU capacity (instruction cycles)	1200	800	1000	1300	900	750	2000
Execution time (seconds)	30	50	40	20	90	40	10

Random values were generated to compute the total number of pages and disk blocks used by the VMs. The number of accesses to memory pages and disk blocks were also computed randomly. Some assumptions were made for creating the same execution environment for both algorithms and to analyze the differences between them.

These assumptions were as follows:

• Maximum CPU capacity of server was 3000 instruction cycles.
• Maximum power capacity of server was 500 kWh.
• Maximum CPU capacity of VM was 1500 instruction cycles.
• Single memory page or disk block was transferred to the destination server through the network connection in 10 s.
• The energy consumed for one second in the transfer process was 10 kWh.
• The time between switching off the VM at the source server and resumption at the destination server was 10 s.
• The setup time of the VM with defined configuration (configuration of VM running on the source server) at the destination server was 5 s.

The next section presents the results of the execution and comparative analysis.

5. Results

The two algorithms were executed, and their results were compared in terms of energy consumption, migration time, downtime, resource utilization, and makespan. The energy consumption analysis is shown in Table 8 and Figure 6.

Table 8. Energy consumption for all scenarios in kWh.

No. of Virtual Machines	LMB	LMEB
3	4997.2	2847.2
4	5983.8	3233.8
5	5193.8	3043.8
6	5220.8	3770.8
7	5624	3474

Figure 6. Energy consumption analysis.

The migration time analysis is shown in Table 9 and Figure 7.

Table 9. Migration time for all scenarios in seconds.

No. of Virtual Machines	LMB	LMEB
3	455	240
4	535	260
5	435	220
6	435	290
7	455	240

Figure 7. Migration time analysis.

The makespan analysis is shown in Table 10 and Figure 8.

Table 10. Makespan for all scenarios in seconds.

No. of Virtual Machines	LMB	LMEB
3	80	130
4	90	90
5	150	190
6	150	150
7	160	210

Figure 8. Makespan analysis.

5.1. Statistical Analysis

The energy consumption values were analyzed in terms of standard deviation and variance to check the validity of the results.

The equation for standard deviation is

$$\mathrm{S} =\sqrt[2]{\frac{1}{N-1}{\sum }_{i=1}^N\left(x\mathrm{i}-\overline{x}\right)}$$

(4)

And the equation for variance is

v = s²

(5)

Using the values in Table 8, the statistical analysis of energy consumption was performed, and the results are presented in Table 11.

Table 11. Results of statistical analysis of energy values.

	LMB	LMEB
Standard deviation	396.17	361.79
Variance	156,950	130,894

5.2. Discussion

The existing and proposed algorithms were analyzed in terms of the parameters explained in Section 1. The details are as follows:

• Energy consumption—The standard deviation and variance were computed, and the results are presented in Table 11. The variance indicates the consistency of the algorithm. The lower the value is, the greater is the consistency is; therefore, LMEB was proved to be more energy efficient than LMB. The average energy consumption of the existing algorithm (LMB) was 5403.92 kWh, and that of the proposed algorithm (LMEB) was 3273.92, so it was reduced by 39%.
• Migration time—According to Table 9, the migration time of LMEB was smaller than that of LMB. The average migration time of LMB was 463 s, and that of LMEB was 250 s, so it was reduced by 46%.
• Downtime—The downtime depends on the network properties between the source and destination servers and was constant for both algorithms in all cases. The downtime value for LMEB was 10 s, and that for LMB was 15 s. LMEB had a smaller downtime value as it does not include the setup time (5 s) of the virtual machine at the destination. The downtime of LMB was 15 s, and that of LMEB was 10 s, so it was reduced by 25%.
• Resource utilization—The values were found to be equal in both algorithms in all cases. So, there were no differences between LMB and LMEB in terms of resource utilization.
• Atomicity and convergence—LMEB was designed in such a way that it preserves atomicity and convergence, as there is only one transfer of data during the post-copy technique, so there are no differences in the data at the source and destination machines; the migration process was not affected by any other resources, so it was successfully completed.
• Makespan—According to Table 10, the makespan of LMEB was found to be larger than that of LMB in some cases. So, LMEB does not guarantee a lowering of the total working time of the servers.

5.3. Complexity

The migration of a virtual machine is not dependent on the number of virtual machines and servers, but it depends on the transmission speed of the network cable from the source to the destination machine; only in this way, the complexity of LMEB is O(t), where t Mbps is the transmission speed.

6. Workflow of Cloud Data Center

After the comparative study, the proposed migration algorithm, LMEB, was found to be more energy efficient and also potentially useful in other applications, such as the IoT, smart city architecture [34,35], the scheduling of various tasks [36,37], etc. The technique of the initial allocation of VMs to the physical server and live VM migration together can contribute to improving the performance of cloud data centers by consuming less energy. The proposed migration algorithm, LMEB, in combination with the bin-packing algorithm DEE-BFD [33], is shown in Figure 9.

Figure 9. Overall workflow of cloud data center.

The workflow starts with taking the configuration of the server in the data center as the input. Thereafter, the process of allocation of VMs to the server is presented through the bin-packing algorithm. After successful allocation, the servers are analyzed to know whether VM migration is required or not. If the answer is yes, then the ballooning technique is implemented along with the LRU algorithm to delete unused memory pages. LRU is the least recently used algorithm for page replacement, which considers the pages that refer to the past as target to be replaced by new pages. This procedure is followed by post-copy and the calculation of the energy value. The whole practice repeats until no VMs are waiting for the service. When there are no more VMs in the waiting list, resource utilization and makespan are calculated to check the functioning of the entire system, so that timely action can be taken for further improvement. The proposed workflow can be used for implementing virtual machine placement with minimum energy [38,39,40,41,42].

The next section presents the concluding remarks.

7. Conclusions

Live VM migration is an important approach to reduce energy consumption along with the bin-packing technique. In this paper, a new algorithm, LMEB, is proposed; LMEB aims at reducing the percentage of energy consumption, downtime, and migration time and maintaining the resource utilization value. The algorithm is also able to achieve the atomicity and convergence properties of migration. By making live VM migration more energy aware, the overall energy requirement and thus the performance of data centers can be upgraded.

As future work, the proposed algorithm could be upgraded with the concept of multiple live VM migrations and in terms of the makespan parameter. The algorithm could also be simulated on any cloud simulator so that other researchers can use it for further extension.