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.
Related documents
zapco STUDIO 100 Specifications
ConVirt v0.9.5
Kingston Tools Ultimate Memory Guide
LE HOW TO DE GENTOO LINUX + DEPLOYEMENT WINDOWS
Sun Blade X6270 M2 Server Module Service Manual
PDF Version - The Munich Network Management Team
Deploy and evaluation of a market-based resource - People
User`s Manual
Installing and configuring
Securing Cloud Hypervisors without Massive Re
Software
Virtualization with Xen
Xen Source Code Overview June 2009
User Manual
Sun Fire X4170 M2 Server Service Manual
Intelligent Power® Protector
snapgear Manual
Oracle Audio Technologies E10898-02 User's Manual
Snapshot/Image Service User Guide
Red Hat ENTERPRISE LINUX 5 - VIRTUALIZATION GUIDE Specifications