150 likes | 210 Views
A comprehensive overview of Xen architecture, including full virtualization and paravirtualization methods, performance overhead, and benefits. Covers paravirtualizing X86 MMU, CPU, device I/O, and virtualization evaluation. Concludes that Xen is scalable, offers great performance isolation, and is ideal for server farm scenarios.
E N D
Xen and the Art of Virtualizationby Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, Andrew Warfield at University of Cambridge Computer Labatory Presented by Yoon-Soo Lee
Full Virtualization • Traditional VM • Full virtualization • Benefit : Unmodified OS can be hosted • Full virtualization of X86 architecture • Was not considered for virtualization • Not easy but still possible • Drawbacks & arguments • Performance overhead • Guest OS might need to see real and virtual resource
Paravirtualization & Xen • Machine abstraction that is similar (but different to) the underlying hardware • Basically another architecture • OS must be modified – to understand virtual environment • ABI not changed • Expose real resource to some extent • Xen - Paravirtualization system developed by the Univ. Cambridge • Goal to host up to 100 commodity OSs • Execution performance close to native • Live migration between VMs • Linux, NetBSD, FreeBSD, WinXP
Paravirtualizing X86 MMU (1) • Does not use shadow-structure • Guest OS responsible for allocating and managing hardware page tables – Minimal Xen Involvement Shadow-mode Direct-mode
Paravirtualizing X86 MMU (2) • Direct-mode avoids overhead of using shadow page tables • Register guest OS page table directly with the MMU • Restrict guest OS to read-only access • Xen must validate PT updates before use • Updates may be queued and batch processed • Xen tracks page ownership • Validation rules applied to each PTE • Guest may only map pages it owns • Pagetable pages may only be mapped RO
Paravirtualizing X86 CPU • Xen runs with most privileged level • Thus called Hypervisor • Guest OS runs on ring 1 • Guest applications run on ring 3 • Hyperviser is protected • Privileged instructions are paravirtualized by requiring them to be validated and executed within Xen • Exception Handling • Xen’s handler creates a copy of exception stack frame on guest OS stack and returns control to the appropriate register handler • Page fault must be treated differently
Paravirtualizing X86 Device I/O • Uses device abstraction instead of emulation • Allows efficient interface • Allows protection and isolation • Hardware interrupts • Lightweight event delivery mechanism • I/O data transferred to and from each domain via Xen using shared memory, asynchronous buffer-descriptor rings
Evaluation • Environment • Hardware • Dell 2650 dual processor 2.4Ghz Xeon server with 2GB RAM, single Hitachi 146GB 10k RPM SCSI disk, 3 Gb Ethernet NIC • Linux 2.4.21 • i686 for native and VMware • Xeno-i686 for Xen • Um for UML • All used same FS and configured to yield best performance
Concurrent VMs Multiple Apache processes in Linux vs. One Apache process in each guest OS
Performance Isolation • 4 domains configured to allocate resource equally • 2 domains running previously measured workload • 2 domains running a pair of antisocial processes • Disk bandwidth hog • Fork bomb • OSDB-IR and SPEC WEB99 4% and 2% below results reported earlier • Sufficient isolation from page-swapping and disk intensive activities
Scalability • Xen reserves 64 MB on boot for a domain • Memory footprint can be reduced to 6.2 MB • With use of swap space can be reduced to 4.2 MB • Need only 20kb for Xen to maintain domain state • Copes well running up to 128 domains
Conclusions • Attempt to paravirtualize X86 architecture for running VMs for commodity OS • Scalable • Performance overhead is small • Performance isolation is great • Good for server farm scenario