Download Chapter 3. The Xen Hypervisor

Transcript
In these experiments, their performance isolation properties varied due to different resource consumptions in
the misbehaving VM, as shown in Table E.2. For each experiment, we reported the percent degradation in good
response rate for both the misbehaving VM and the average for the three well-behaving VMs.
Table E.2. Performance Isolation Evaluation on Xen (Xen 3.0)
Resource Consumption
Well-Behaving
Misbehaving
Memory
0.03
DNR
Fork
0.04
DNR
CPU
0.01
0
DISK IO
1.67
11.53
Network Receiving
0
0.33
Network Transmitting
0.04
0.03
Table E.2 illustrates the importance of considering multiple types of "misbehavior" when evaluating the
performance isolation properties of a virtualization system. If we looked only at the CPU intensive resource
experiment results, our conclusion would have been different than if we had considered the disk and network
intensive experiments, or the memory intensive and fork bomb experiments.
In the presence of an intensive CPU stress application running in the misbehaving VM, Xen performed well on
this experiment—even in the misbehaving VM. We verified that the CPU load on the misbehaving VM did rise to
nearly 100%. We suspected that the normal OS CPU scheduling algorithms were already sufficient to allow the
Web server sufficient CPU time. In the memory case, SPECweb in the Xen's misbehaving VM could not report
results at all due to the VM running out of memory, but all other well-behaving guests continued to report
nearly 100% good results. When the fork bomb ran in the guest, the misbehaving VM presented no results, but
the other three well-behaving containers continued to report nearly 100% good response time. When IOzone
benchmark ran in the guest, Xen reports a mixed situation. The misbehaving VM saw a degradation of 12%, and
the other three VMs were also impacted, showing an average degradation of 1% to 2%. In the network
receiving experiment, the misbehaving virtual machine acted as the packet receiver and continuously received
packets from an external malicious physical machine. The results showed that the well-behaving VMs had no
degradation and the misbehaving VMs showed a slight, but repeatable, degradation of less than 1%. In the
network transmitting experiment, the misbehaving virtual machine acted as the packet sender, sending packets
to an external physical machine. The misbehaving and well-behaving VMs in Xen were both similarly affected
with a very slight degradation of 0.03% to 0.04%.
Overall, the results in Table E.2 indicate that Xen protects the well-behaving VMs. The average degradation for
the disk intensive case is the worst at 1.67%. One thing that this table highlights, however, is a slight but
consistent degradation on most experiments. More comparisons among VMware Workstation, OpenVZ, and
Solaris containers are presented in the original paper.