210 likes | 312 Views
The xCloud and Design Alternatives. Presented by Lavone Rodolph. Overview. Definition of Virtualization Why Virtualization is hot Two major v irtualization hypervisor platforms Cloud Providers Major cloud provider problem for cloud users Solutions to problem Testing Results.
E N D
The xCloud and Design Alternatives Presented by Lavone Rodolph
Overview • Definition of Virtualization • Why Virtualization is hot • Two major virtualization hypervisor platforms • Cloud Providers • Major cloud provider problem for cloud users • Solutions to problem • Testing Results
Virtualization Definition • “Virtualization is the creation of a virtual device or resource such as a server, storage device, network or even an operating system” [3]
Why virtualization is hot • The 4 drivers of virtualization • Hardware is underutilized • Data Centers run out of space • Energy Cost is high • System administration cost mounts
Two Major Virtualization VMM Platforms • Xen • KVM
Xen Hypervisor Platform 2 Main Components: • Hypervisor (VMM) – manages memory, CPU scheduling, etc. • VM0 (Domain 0) – has direct access to HW. Provides device drivers and I/O mgmt. for guest VM’s • Paravirtualization replaces all privileged instructions with direct calls to hypervisor
KVM Hypervisor • 4 privilege levels • Rings 0-3 • Ring 0 (Most Privileged) controls HW& Sys. Functions • KVM model depends on architecture set. Ex. In X86 Guest OS runs in Ring 3, Rings 1 & 2 not used.
Cloud Providers • Amazon (EC2) • Google • IBM • Microsoft • Rackspace • Salesforce
Cloud Provider Problems • Immutable Hypervisor and Buried HW • Users are dependent on Cloud Vendor hypervisor tools • Ex.) Amazon EC2 – CloudWatch Monitoring tool, Elastic load balancing. • Users can not create custom hypervisor tools or employ techniques (such as efficient page sharing) at the hypervisor level. • HW details lies behind virtual abstraction. Users can only use HW interfaces exposed by cloud provider
Solution: General Extensibility Architecture • Note: U = User modules, P = Provider modules • Allows user to create custom hypervisor modules. • Interact directly with provider modules and with HW. • Provide better service, enhanced performance • Note: Provider Modules multiplex HW & enforce protection (isolate containers)
Three Design Alternatives • The Extensible Hypervisor Design • Download custom extensions (grafts or modules) into hypervisor. • The ExoHypervisor Design • Expose HW through the hypervisor via custom VMMLibraries • The Nested virtualization approach • Add another Virtual Machine Monitor (Hypervisor) that user can control
The Extensible Hypervisor Design • Allows user to have some control of the hypervisor by downloading custom modules/extensions into the kernel • Based on extensible OS ex. (SPIN & VINO) • User defined modules make hypervisor mutable • Modules execute in privilege mode, can access HW
The Extensible Hypervisor Design • Immutable modules must be protected. • Safe languages (ex. Modual-3) are used to protect immutable modules • Software fault isolation protect modules
The ExoHypervisorDesign • VMMlibrary used to manage HW, instead of Kernel, kernel enforces protection between applications • VMMLibrary can be custom built • Library can be linked to application • Allows users to access HW • Based on ExokernelOS • LibVMM is mutable
Nested Virtualization Approach • User modules made in the user controlled VM • HW still remains buried • However, paravirtualization may be applied • Provider involvement is not necessary
Testing Nested Virtualization Design • Nested virtualization testing performed within Amazon EC2 on machines with 24GB of RAM, 6 dual core 2.3GHz Intel Xeon X5670 Processors.
Testing Results 1 • Below are microbenchmark testing results using lmbench for performing the following operations: double division, null system calls and fork. • PV invokes hypervisor on system call. • PV Fork causes overhead by inducing traps in lower layer hypervisor (it’s not privileged to do so)
Testing Disk I/O • Testing I/O by writing 1.6 GB of data to a disk partition using blocks of size 256K. Tested 5 times • Results: Nested virtualization did not cost much overhead, it achieved 90% throughput
References • 1. ELDEHIRY, M., ELNIKETY, E., HUANG, H., JAMJOOM, H ,. WEATHERSPOON, H., AND WILLIAMS, D. Unshackle the Cloud! In Proc. of USENIX HotCloud’11 (Portland, OR, June 2011). • 2. BARHAM, P., DRAGOVIC, B., FRASER, K., HAND, S., HARRIS, T., HO, A., NEUGEBAUER, R., PRATT, I., AND WARFIELD, A. Xen and the art of virtualization. In Proc. of ACM SOSP (Bolton Landing, NY, Oct. 2003). • 3. BEN-YEHUDA, M., DAY, M. D., DUBITZKY, Z., FACTOR, M., HAR’EL, N., GORDON, A., LIGUORI, A., WASSERMAN, O., AND YASSOUR, B.- A. The turtles project: Design and implementation of nested virtualization. In Proc. of USENIX OSDI (Vancouver, BC, Canada, Oct. 2010).
References (cont.) • 4. BERSHAD, B. N., SAVAGE, S., PARDYAK, P., SIRER, E. G., FIUCZYN- SKI, M. E., BECKER, D., CHAMBERS, C., AND EGGERS, S. Extensibil- ity, safety and performance in the SPIN operating system. In Proc. of ACM SOSP (Copper Mountain, CO, Dec. 1995). • 5. CLARK, C., FRASER, K., HAND, S., HANSEN, J. G., JUL, E., LIMPACH, C., PRATT, I., AND WARFIELD, A. Live migration of virtual machines. In Proc. of USENIX NSDI (Boston, MA, May 2005). • 6. http://searchservervirtualization.techtarget.com/definition/virtualization