# A Virtual Network Resource Allocation Framework Based on SR-IOV
## 5 Evaluation
### Dynamic Scheduling  
First, we test the attribute characteristics of the SR-IOV-based virtual resource allocation framework under dynamic hybrid load. We run 15 VMs on the same host, _VM1_-_VM15_, and the VMs are divided into three categories, each with 5 VMs. As shown in Table 2, The VMs in each \begin{table}
\begin{tabular}{c c} \hline CPU & Intel(R) Xeon(R) E5-2630 v4 @ 2.20 GHz \\ RAM & DDR4 ECC RG 64 GB \\ NIC & Intel 82599 10 Gbps \\ VMM & KVM 1.5.3/QEMU 1.5.3 \\ DomO OS & CentOS 7.5 (Linux 3.10.0 SMP) \\ VM OS & CentOS 6.9 (Linux 2.6.32 SMP) \\ VM RAM & 512M \\ VM NIC & Intel 82599 VF \\ \hline \end{tabular}
\end{table} 
Table 1: Server configuration. group simulate network-intensive (VM1-VM5), CPU-intensive (VM6-VM10), and mixed-load VMs (VM11-VM15), respectively, and the proportion of time in which the benchmarks are run in the order of increasing VM IDs in each group is 20%, 40%, 60%, 80%,100%. Table 2 shows the differences that the system exhibits when running at different loads. From the table we can see that the _io_degree_ value of CPU-intensive VM is always lower than that of network-intensive VM, and the longer the benchmark running time of the CPU-intensive VM, the lower its _io_degree_ value. In addition, for a mixed-load VM, its _io_degree_ value is also larger than the CPU-intensive VM. By judging the value of _io_degree_, we can judge the network-intensive VM and the mixed-load VM with a large network density. In addition, as shown in the table, the longer the _Netperf_ runtime of a network-intensive VM, the greater its _net_degree_ value. Therefore, combining the _net_degree_ value of the VM, the VM with high network density can be judged. To test whether our proposed allocation framework can distinguish between network-intensive VMs and dynamically assign VF to network-intensive VMs, we run 8 VMs on the same host and configure the number of VFs to be 4. In addition, the VF Scheduler is triggered for every 10 s and the parameter \(\delta\) is set to 0.7 when _net_degree_ is calculated. Table 3 shows how the load on each VM changes over time. Among them, the proportion of time that _VM1_ runs _Netperf_ has been kept at 55%, the proportion of time that _VM2_ runs _Lookbusy_ is 40%, and the proportion of time that _VM3_ runs both _Netperf_ and _Lookbusy_ is 30%. The load of other VMs will change with time, so we can test the allocation status of VF when the load changes. Experiments show that before time point 10, because _VM1_, _VM6_, _VM7_ and _VM8_ have the largest _net_degree_ value, these four VMs are assigned VF. There is a scheduling occurred at time 10 because _VM7_ and _VM8_ became CPU-intensive VMs, and their VFs were removed and assigned to _VM3_ and _VM5_. Later, in the moment of 20, there is a VF who owners are changed as the network density of _VM4_ is increased and its _net_degree_ is greater than the value of _VM3_. Finally, at time 30, no VF removal and allocation occurs, because although the network density of _VM8_ is increased, it is also a CPU-intensive \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**VM\_id** & **VM1** & **VM2** & **VM3** & **VM4** & **VM5** \\ \hline io\_degree & 91.45 & 90.95 & 92.43 & 94.07 & 93.98 \\ net\_degree & 27,703 & 52,832 & 104,386 & 146,989 & 162,072 \\ \hline
**VM\_id** & **VM6** & **VM7** & **VM8** & **VM9** & **VM10** \\ \hline io\_degree & 81.43 & 59.97 & 45.54 & 23.61 & 7.82 \\ net\_degree & 0 & 0 & 0 & 0 & 0 \\ \hline
**VM\_id** & **VM11** & **VM12** & **VM13** & **VM14** & **VM15** \\ \hline io\_degree & 86.23 & 61.98 & 45.77 & 25.09 & 11.73 \\ net\_degree & 30,283 & 69,032 & 95,619 & 138,566 & 175,117 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: CPU-intensive, network-intensive and mixed-load property values.