## 4 Solution for MCRC Problem
### VM Placement
A VM migration costs 10% extra resources; hence, the host reserves 10% resources for migrations. Based on this, we set \(TH_{up}^{cpu}=TH_{up}^{disk}=TH_{up}^{net}=0.9\). We also set \(TH_{down}^{cpu}=TH_{down}^{mem}=TH_{down}^{disk}=TH_{down}^{net}=0.1\). \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Host Type** & **CPU** & **Memory** & **Disk Throughput** & **Network Throughput** \\ \hline \(H_{large}\) & 4 times Intel Xeon Northwood CPU (single core) & 8 GB & 399 MB/s & 1 GB/s \\ \(H_{medium}\) & 3 times Intel Xeon Northwood CPU (single core) & 6 GB & 266 MB/s & 1 GB/s \\ \(H_{small}\) & 2 times Intel Xeon Northwood CPU (single core) & 4 GB & 133 MB/s & 1 GB/s \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Resource parameters of the hosts. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Host Type** & **Value** & **CPU (kW)** & **Memory (kW)** & **Disk (kW)** & **NIC (kW)** \\ \hline \(H_{large}\) & \(p_{peak}\) & 0.232 & 0.21736 & 0.02106 & 0.002 \\  & \(p_{ulle}\) & 0.1124 & 0.17576 & 0.01326 & 0.00078 \\ \hline \(H_{medium}\) & \(p_{peak}\) & 0.174 & 0.10868 & 0.01404 & 0.002 \\  & \(p_{ulle}\) & 0.843 & 0.08788 & 0.00884 & 0.00078 \\ \hline \(H_{small}\) & \(p_{peak}\) & 0.116 & 0.05434 & 0.00702 & 0.002 \\  & \(p_{ulle}\) & 0.562 & 0.04394 & 0.00442 & 0.00078 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Power parameters of the hosts. ### Evaluation

In the evaluation, four overloading detection algorithms (MAD [6], IQR [6], and LR [6]), three VM selection algorithms (MMT [6; 31; 39], MC [6; 55], and RS [6]), and one VM placement algorithm (PABFD [6]) are combined as nine methods to compare with our proposed solution. The PABFD placement algorithm and its corresponding energy consumption model only take into account the host's CPU. Therefore, we modify it here to suit our multi-resource scenario. The new PABFD placement algorithm is PABFDM, see Algorithm 2 for the pseudo-code. ```
0: hostList, vmList
0: allocation of the VMs
1: vmList.sortDecreasingUtilization()
2:for each VM in vmList do
3: minPower \(\leftarrow\) MAX
4:for host in hostList do
5:ifno SLAV on this host and this host meets the CPU, memory, disk and network resource requirement for VM then
6: power \(\leftarrow\) estimatePower(host,VM)
7:if power<minPower then
8: minPower\(\leftarrow\)power
9:endif
10:endif
11:endfor
12: allocation.add(VM,host)
13:endforreturn allocation
```

**Algorithm 2** PABFDM algorithm. The naming rule of the baseline methods is 'xx-xx'. For instance, LR-MMT indicates that the combination uses LR for overloading detection and MMT for VM selection. We denote our proposed method as ARP-TSCP. The metrics involved are host-operation-related costs, SLAV cost, and the number of VM migrations. Since the CPU part of the VM migration energy consumption belongs to the host's energy consumption during calculation, we use the number of VM migrations to indirectly measure the migration cost. Figure 10 demonstrates the energy consumption comparison of all hosts using ARP-TSCP and the nine baseline methods in 288 consecutive periods. Figure 11 demonstrates the comparison of the total energy consumption of all hosts using these two methods to consolidate servers throughout the day. It can be seen in Figure 10 that, throughout most of the period, the host energy consumption produced by ARP-TSCP is lower than that produced by the baseline methods. Therefore, in the comparison of the total host energy consumption, ARP-TSCP outperforms the baseline methods. The total host energy consumption generated by executing ARP-TSCP in one day is about 18.5% lower than that generated by executing LR-MMT (the best result of all baseline methods) and is about 30.3% lower than that of MAD-RS (the worst result of all baseline methods), as shown in Figure 11.

Figure 12 demonstrates the comparison of the total SLAV of CPU, memory, disk, and network generated by ARP-TSCP and the baseline methods in one day respectively.