1. Presented by Yoon-Soo Lee
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

2. Xen Architecture Overview

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. I/O Virtualization

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

11. Relative Performance

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

13. 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

14. 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

15. 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