Xen and the Art of Virtualization by Paul

Xen and the Art of Virtualization by 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

Xen Architecture Overview

Full Virtualization l Traditional VM l Full virtualization l Benefit : Unmodified OS can be hosted l Full virtualization of X 86 architecture Was not considered for virtualization l Not easy but still possible l l Drawbacks & arguments l Performance overhead l Guest OS might need to see real and virtual resource

Paravirtualization & Xen l Machine abstraction that is similar (but different to) the underlying hardware l Basically another architecture l l 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 l l Goal to host up to 100 commodity OSs Execution performance close to native Live migration between VMs Linux, Net. BSD, Free. BSD, Win. XP

Paravirtualizing X 86 MMU (1) l Does not use shadow-structure l Guest OS responsible for allocating and managing hardware page tables – Minimal Xen Involvement Shadow-mode Direct-mode

Paravirtualizing X 86 MMU (2) l Direct-mode avoids overhead of using shadow page tables l Register guest OS page table directly with the MMU l Restrict guest OS to read-only access l Xen must validate PT updates before use l l l Updates may be queued and batch processed Xen tracks page ownership Validation rules applied to each PTE l l Guest may only map pages it owns Pagetable pages may only be mapped RO

Paravirtualizing X 86 CPU l Xen runs with most privileged level l Thus called Hypervisor l l Guest OS runs on ring 1 Guest applications run on ring 3 l Hyperviser is protected l Privileged instructions are paravirtualized by requiring them to be validated and executed within Xen Exception Handling l l l 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 X 86 Device I/O l Uses device abstraction instead of emulation l Allows efficient interface l Allows protection and isolation l Hardware interrupts l Lightweight l event delivery mechanism I/O data transferred to and from each domain via Xen using shared memory, asynchronous buffer-descriptor rings

I/O Virtualization

Evaluation l Environment l Hardware l l Dell 2650 dual processor 2. 4 Ghz Xeon server with 2 GB RAM, single Hitachi 146 GB 10 k RPM SCSI disk, 3 Gb Ethernet NIC Linux 2. 4. 21 i 686 for native and VMware l Xeno-i 686 for Xen l Um for UML l l All used same FS and configured to yield best performance

Relative Performance

Concurrent VMs Multiple Apache processes in Linux vs. One Apache process in each guest OS

Performance Isolation l 4 domains configured to allocate resource equally l l 2 domains running previously measured workload 2 domains running a pair of antisocial processes Disk bandwidth hog l Fork bomb l l l OSDB-IR and SPEC WEB 99 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 l Memory footprint can be reduced to 6. 2 MB l l With use of swap space can be reduced to 4. 2 MB Need only 20 kb for Xen to maintain domain state l Copes well running up to 128 domains l

Conclusions Attempt to paravirtualize X 86 architecture for running VMs for commodity OS l Scalable l l Performance overhead is small l Performance isolation is great l Good for server farm scenario