Xen and the art of virtualization

P. BarhamBoris DragovicK. FraserS. HandTim HarrisAlex HoR. NeugebauerI. PrattA. Warfield

article2003SOSP1,590 citations

Introduces the Xen hypervisor and the concept of paravirtualization, demonstrating how modifying guest operating systems enables x86 servers to securely run dozens of concurrent virtual machines with near-native performance.

Listen

Modern enterprise computing increasingly relies on partitioning powerful physical servers to run multiple isolated workloads simultaneously. However, traditional virtualization on standard computing architectures faces severe challenges: full virtualization requires complex software emulation that significantly degrades system performance, while lightweight process-level sharing fails to provide strict security and resource isolation between competing users. The article presents Xen, a high-performance virtual machine monitor that solves this dilemma by introducing paravirtualization—an approach that slightly modifies hosted operating systems to work cooperatively with the underlying hypervisor without altering user-level software applications.

The primary objective of the article is to design, implement, and evaluate a virtualization platform that enables up to 100 concurrent operating system instances to run on standard server hardware with strong performance isolation and near-native execution speed. To demonstrate this capability, the authors ported standard Linux and prototype Windows systems to Xen. They then conducted an extensive experimental evaluation comparing Xen against unvirtualized bare-metal Linux and existing commercial and open-source virtualization solutions across standardized industry benchmarks, database workloads, web serving tasks, and hostile multi-tenant stress tests.

The evaluation revealed several critical findings. First, Xen achieves performance virtually identical to non-virtualized hardware across complex server workloads, exhibiting less than a 1% performance penalty on web-serving benchmarks and a mere 3% overhead during software compilation. In stark contrast, competing full-virtualization and user-space solutions supported less than one-third of the native workload capacity and suffered substantial execution penalties. Second, porting standard operating systems requires minimal engineering effort; modifying Linux to run on Xen required altering less than 1.4% of its architecture-specific source code. Third, Xen demonstrated robust performance isolation, maintaining 96% to 98% of expected throughput on production database and web benchmarks even when co-located with malicious domains executing fork bombs and intensive disk-swapping attacks. Finally, Xen scales effectively to over 100 concurrent virtual machines, exhibiting only a 7.5% total throughput loss under heavy multi-domain competition while keeping individual domain memory footprints as low as 4 to 6 megabytes.

These findings indicate that high-density server consolidation and multi-tenant hosting can be achieved without compromising application performance, system predictability, or administrative control. By eliminating the heavy performance penalties of full virtualization and separating management policy from low-level execution mechanisms, Xen significantly reduces hardware and infrastructure operational costs. The trade-off requires adopting modified operating system kernels, but because user applications run entirely unmodified, deployment friction remains low.

Based on these results, organizations deploying multi-tenant cloud platforms, distributed web services, or consolidated server environments should evaluate paravirtualized architectures for production rollouts. Moving forward, the platform development roadmap focuses on publicly releasing the software, completing the porting and device driver support for enterprise operating systems like Windows XP, and implementing advanced storage optimizations such as shared copy-on-write disk caches and market-driven accounting mechanisms. While confidence in Xen's processing, memory, and networking performance is high, readers should note that current disk scheduling remains relatively simple and requires further refinement to ensure proportional I/O performance differentiation under heavily saturated synchronous workloads.

No sufficiently relevant recommendations were found.

  • Paper: Live migration of virtual machines, Christopher J. Clark et al. (2005). Extends the Xen paravirtualization architecture by developing an iterative pre-copy live migration technique for running virtual machines between physical datacenter hosts with minimal downtime.
  • Paper: Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center, Benjamin Hindman et al. (2011). Addresses the resource utilization and multi-tenancy limits of static server partitioning and coarse virtualization by introducing a fine-grained, dynamic cluster resource-sharing platform.
Cover for Xen and the art of virtualization

Abstract

Numerous systems have been designed which use virtualization to subdivide the ample resources of a modern computer. Some require specialized hardware, or cannot support commodity operating systems. Some target 100% binary compatibility at the expense of performance. Others sacrifice security or functionality for speed. Few offer resource isolation or performance guarantees; most provide only best-effort provisioning, risking denial of service.

This paper presents Xen, an x86 virtual machine monitor which allows multiple commodity operating systems to share conventional hardware in a safe and resource managed fashion, but without sacrificing either performance or functionality. This is achieved by providing an idealized virtual machine abstraction to which operating systems such as Linux, BSD and Windows XP, can be ported with minimal effort.

Our design is targeted at hosting up to 100 virtual machine instances simultaneously on a modern server. The virtualization approach taken by Xen is extremely efficient: we allow operating systems such as Linux and Windows XP to be hosted simultaneously for a negligible performance overhead — at most a few percent compared with the unvirtualized case. We considerably outperform competing commercial and freely available solutions in a range of microbenchmarks and system-wide tests.

Table of Contents

  • Categories and Subject Descriptors
  • General Terms
  • Keywords
  • 1. INTRODUCTION
  • 2. XEN: APPROACH & OVERVIEW
  • 2.1 The Virtual Machine Interface
  • 2.1.1 Memory management
  • 2.1.2 CPU
  • 2.1.3 Device I/O
  • 2.2 The Cost of Porting an OS to Xen
  • 2.3 Control and Management
  • 3. DETAILED DESIGN
  • 3.1 Control Transfer: Hypercalls and Events
  • 3.2 Data Transfer: I/O Rings
  • 3.3 Subsystem Virtualization
  • 3.3.1 CPU scheduling
  • 3.3.2 Time and timers
  • 3.3.3 Virtual address translation
  • 3.3.4 Physical memory
  • 3.3.5 Network
  • 3.3.6 Disk
  • 3.4 Building a New Domain
  • 4. EVALUATION
  • 4.1 Relative Performance
  • 4.2 Operating System Benchmarks
  • 4.2.1 Network performance
  • 4.3 Concurrent Virtual Machines
  • 4.4 Performance Isolation
  • 4.5 Scalability
  • 5. RELATED WORK
  • 6. DISCUSSION AND CONCLUSION
  • 6.1 Future Work
  • 6.2 Conclusion
  • Acknowledgments
  • 7. REFERENCES

Knowls

  1. Knowl 1 — Xen Paravirtualization Architecture and Design Principles

    model/method

    Xen employs paravirtualization, an approach that presents an idealized virtual machine abstraction that is similar but not identical to the underlying hardware architecture (specifically x86). Rather than enforcing full hardware virtualization via trap-and-emulate or dynamic binary translation, paravirtualization modifies the guest operating system source code while strictly preserving the existing Application Binary Interface (ABI) so that user-space binaries execute unmodified.

    The Xen virtualization model is governed by four core design principles:

    1. Support for unmodified application binaries: The hypervisor must virtualize all architectural features required by existing standard ABIs (e.g., x86 segmentation and standard system call interfaces).

    2. Support for full multi-application operating systems: Guest operating systems must be able to securely host and multiplex multiple independent address spaces and user-space processes within a single virtual machine instance.

    3. Paravirtualization on uncooperative architectures: Paravirtualizing hardware interfaces is necessary to achieve near-native performance and strong resource isolation on architectures like x86, which contain non-virtualizable, silently failing privileged instructions and hardware-managed page tables.

    4. Selective exposure of physical hardware details: Completely concealing physical resource characteristics harms performance and correctness. Guest operating systems are exposed to both virtual and real time (to properly manage TCP round-trip times and timeouts) and physical machine addresses (to enable OS-level optimizations such as superpages and page coloring).

  2. Knowl 2 — Direct Hardware Page Table Virtualization with Type and Reference Counting

    model/method

    To eliminate the performance overhead and complexity of shadow page tables on x86 architectures with hardware-walked page tables, Xen directly registers guest OS page tables with the memory management unit (MMU) while enforcing safety through a validation and type-pinning mechanism.

    When a guest OS allocates a new page table (e.g., upon creating a process), it allocates a frame from its own memory reservation and registers it with Xen. The guest relinquishes direct write privileges to this memory, making the page table read-only to the guest OS. All subsequent page table modifications must be submitted to Xen via hypercalls for validation.

    To ensure memory isolation and structural safety, Xen assigns each machine page frame a mutually exclusive type and a reference count. The allowable page types are:

    • Page Directory (PD)
    • Page Table (PT)
    • Local Descriptor Table (LDT)
    • Global Descriptor Table (GDT)
    • Writable (RW)

    A page frame can only be retasked to a different type when its reference count drops to zero. This invariant prevents a domain from having a writable mapping to a frame that is currently in use as a page table (which would require the frame to simultaneously be typed as PT/PD and RW). To avoid re-validating the page table structure on every context switch, a guest OS can pin a frame's type to PD or PT until an explicit unpin hypercall is made.

    To amortize hypercall transition overheads, guest operating systems batch multiple page table updates into a local queue (holding up to 2048 updates) and apply them via a single hypercall prior to TLB flushes.

    Additionally, Xen maps itself into a reserved 64MB section at the top of every domain's virtual address space. Because this 64MB region is avoided by standard x86 ABIs, hypervisor entry and exit do not require flushing the processor's translation lookaside buffer (TLB).

  3. Knowl 3 — x86 CPU and Privilege Level Virtualization

    model/method

    Xen virtualizes the x86 CPU by exploiting hardware privilege levels (rings 0 through 3):

    • Ring 0 (Most Privileged): Dedicated entirely to the Xen hypervisor.
    • Ring 1: Assigned to guest operating system kernels, preventing them from directly executing privileged processor instructions while maintaining isolation from user applications.
    • Ring 3 (Least Privileged): Assigned to unmodified guest user-space applications.

    Privileged instructions (such as CPU state modification or yielding the processor when idle) attempted in Ring 1 fail or trap and are converted into synchronous hypercalls to Xen.

    Hardware exceptions (such as memory faults and software traps) are virtualized through exception descriptor tables registered by the guest OS with Xen. Xen validates that registered handlers do not specify Ring 0 code segments. When an exception occurs, Xen saves processor state, copies the exception stack frame onto the guest OS stack in Ring 1, and redirects execution to the registered guest handler.

    Two critical exceptions receive special optimizations:

    • System Calls: A guest OS can install a validated 'fast' handler directly into the hardware exception table. This enables user applications in Ring 3 to enter the guest OS in Ring 1 directly without trapping into Xen on every system call.
    • Page Faults: Because reading the faulting virtual address from register CR2 requires Ring 0 privilege, page faults trap to Xen, which copies CR2 into an extended stack frame on the guest OS stack before delivering control to the guest OS page fault handler in Ring 1.
  4. Knowl 4 — Asynchronous I/O Descriptor Ring Architecture

    model/method

    Xen provides an asynchronous, zero-copy I/O mechanism between guest domains and the hypervisor using shared-memory circular descriptor queues termed I/O rings.

    An I/O ring contains descriptors that reference out-of-band data buffers allocated by the guest OS. Access to each ring is synchronized via two pairs of producer-consumer pointers:

    • Request Production and Consumption: The guest domain enqueues requests and advances a shared Request Producer pointer. Xen reads incoming requests and advances its private Request Consumer pointer.
    • Response Production and Consumption: Xen enqueues completion responses and advances a shared Response Producer pointer. The guest domain processes responses and advances its private Response Consumer pointer.
    Request Consumer (Private pointer in Xen)
    Request Producer (Shared pointer updated by guest OS)
    Response Producer (Shared pointer updated by Xen)
    Response Consumer (Private pointer in guest OS)
    

    Descriptors carry unique transaction identifiers that are echoed in the corresponding responses. This decouples request submission from completion, allowing Xen to process and complete I/O operations (such as disk blocks) out of order based on priority or elevator scheduling.

    Notification is decoupled from descriptor production: guest domains can enqueue multiple requests before invoking a hypercall to notify Xen, and Xen can defer event delivery until a specified threshold of completed responses is reached.

  5. Knowl 5 — Control and Management Architecture via Domain0

    model/method

    Xen strictly separates hypervisor mechanisms from high-level management policy. The hypervisor implements basic data-path mechanisms (CPU scheduling, packet filtering, block access control, and memory validation) while delegating policy decisions and system management to an initial privileged virtual machine called Domain0.

    Domain0 is automatically booted by Xen at startup and runs application-level management software in a modified operating system (such as XenoLinux). Through a privileged control interface exported by Xen, Domain0 can:

    • Create, build, and destroy other virtual machine domains.
    • Dynamically allocate and adjust physical memory quotas and scheduling parameters for guest domains.
    • Instantiate, configure, and teardown Virtual Network Interfaces (VIFs) and Virtual Block Devices (VBDs).
    • Define packet filtering rules, firewall configurations, and device access permissions.

    Domain building is offloaded from Xen to Domain0: Domain0 parses the guest OS image, constructs its initial boot-time memory layout, initializes page tables, and registers the initial virtual CPU register state with Xen via control hypercalls.

  6. Knowl 6 — Network Virtualization via Virtual Firewall-Router and Page-Flipping

    model/method

    Xen provides network virtualization through the abstraction of a Virtual Firewall-Router (VFR), to which each domain connects via one or more Virtual Network Interfaces (VIFs).

    Each VIF consists of a pair of asynchronous transmit and receive I/O descriptor rings:

    • Transmit Data Path: The guest OS enqueues buffer descriptors on its transmit ring. Xen copies the packet header to validate it against a list of (<pattern>, <action>) filter rules configured by Domain0 (e.g., preventing IP source address spoofing). The packet payload is transmitted zero-copy directly from pinned guest page frames using scatter-gather DMA.
    • Receive Data Path (Page-Flipping): To avoid data copying during packet reception, the guest OS allocates and enqueues empty, page-aligned physical memory frames on its receive ring. When a packet arrives, Xen inspects the header against VFR routing rules to identify the target VIF and exchanges the hardware page frame containing the incoming packet with an unused page frame from the target domain's receive ring. If no receive frame is available, the packet is dropped.
  7. Knowl 7 — Storage Virtualization via Virtual Block Devices

    model/method

    In Xen, only Domain0 possesses direct, unchecked access to physical storage hardware (IDE/SCSI). All other guest domains access persistent storage via Virtual Block Devices (VBDs).

    A VBD represents a collection of disk extents configured with ownership and access permissions (read-only or read-write) by Domain0. Within Xen, a VBD translation table maps (VBD ID, sector offset) pairs to physical disk sectors and physical drive identifiers.

    Guest domains submit read and write requests over I/O descriptor rings. Zero-copy data transfer is executed via DMA between physical storage controllers and pinned guest memory frames. Xen services request batches from competing domains in round-robin order and feeds them into a standard elevator disk scheduler.

    Because Xen can reorder block requests for scheduling efficiency, guest operating systems may insert explicit reorder barriers into the request descriptor queue to enforce serialization semantics required by transactional file systems and write-ahead logs.

  8. Knowl 8 — Physical Memory Partitioning and Address Translation

    model/method

    Xen manages physical memory through static reservation and dynamic ballooning across domains:

    • Memory Reservations: Each domain is allocated an initial memory reservation at creation and assigned a maximum allowable memory limit. Memory frames allocated to a domain are typically discontiguous in physical machine space.
    • Address Translation: The guest OS maintains a physical-to-machine translation table to present a contiguous physical address space abstraction to internal OS subsystems. Xen provides a globally shared machine-to-physical translation array that all domains can read directly; updates are validated by Xen to ensure page ownership.
    • Balloon Driver: Dynamic memory reclamation is implemented via an OS-level balloon driver. To reduce footprint, the balloon driver allocates pages from the guest OS page allocator and returns the underlying machine frames to Xen. To expand memory up to the maximum reservation, it claims new pages from Xen and passes them into the guest allocator.
    • Hardware Address Visibility: Exposing actual machine addresses allows guest operating systems to implement physical optimizations, such as mapping contiguous machine frames into superpages or performing page coloring for physically indexed caches.
  9. Knowl 9 — Control Transfer via Hypercalls and Asynchronous Event Channels

    model/method

    Control transfer between Xen and guest operating systems is structured around two distinct abstractions:

    1. Hypercalls (Domain to Xen): Synchronous control transfers initiated by the guest OS via a software trap instruction from Ring 1 into Ring 0. Hypercalls serve an analogous function to system calls in conventional operating systems, allowing a domain to request privileged operations such as page table updates, memory allocation adjustments, and I/O submission notifications.

    2. Events (Xen to Domain): Lightweight asynchronous notifications from Xen to guest domains, replacing hardware interrupts. Xen sets a bit in a per-domain pending-event bitmask and calls a registered event-callback handler in the guest OS. Events signal conditions such as network packet arrivals, disk I/O completions, timer expirations, and domain termination requests.

    A guest domain can mask event delivery by setting a shared, Xen-readable software flag, providing a software mechanism analogous to disabling hardware CPU interrupts.

  10. Knowl 10 — Macrobenchmark Performance Comparison of Xen, Native Linux, VMware, and UML

    data/table

    Application-level macrobenchmarks were conducted on a dual-processor 2.4 GHz Intel Xeon server with 2 GB RAM and a 146 GB 10k RPM SCSI disk (configured with a single active CPU for uniprocessor comparison). Linux 2.4.21 was evaluated under Native Linux (L), XenoLinux on Xen (X), VMware Workstation 3.2 (V), and User-Mode Linux skas3 (U).

    Benchmark Native Linux (L) XenoLinux (X) VMware 3.2 (V) UML (U)
    SPEC INT2000 (score) 567 567 554 550
    Linux kernel build time (s) 263 271 334 535
    OSDB-IR (tuples/s) 172 158 80 65
    OSDB-OLTP (tuples/s) 1714 1633 199 306
    dbench (score) 418 400 310 111
    SPEC WEB99 (score) 518 514 150 172

    These measurements demonstrate:

    • In compute-bound workloads with minimal OS interaction (SPEC INT2000), virtualization overhead is negligible across all systems (Xen: 0% overhead; VMware: 2.3% overhead; UML: 3.0% overhead).
    • In OS-intensive workloads involving frequent page table updates, file I/O, and network processing (kernel build, OSDB, dbench, SPEC WEB99), XenoLinux incurs minimal overhead (within 1% on SPEC WEB99 and within 3% on kernel compilation relative to native Linux).
    • Full virtualization (VMware Workstation) and user-space emulation (UML) exhibit severe performance degradation on I/O- and MMU-intensive workloads (e.g., in OSDB-OLTP and SPEC WEB99, supporting less than one-third of native throughput due to shadow page table traps and ring emulation).
  11. Knowl 11 — Microbenchmark Latency and Network Throughput Overheads

    data/table

    Subsystem performance and virtualization latencies were evaluated using lmbench (times in μ\mus) and ttcp network bandwidth (in Mb/s) on a 2.4 GHz Xeon system comparing native uniprocessor Linux (L-UP), native SMP Linux (L-SMP), XenoLinux (Xen), VMware Workstation 3.2 (VMW), and User-Mode Linux (UML).

    lmbench Operation (μ\mus) L-SMP L-UP Xen VMW UML
    Null system call 0.53 0.45 0.46 0.73 24.7
    Null I/O 0.81 0.50 0.50 0.83 25.1
    Signal handler install 2.10 1.28 1.22 1.88 36.1
    Signal handle latency 3.51 1.92 1.88 2.99 62.8
    Process fork 143 110 198 874 21000
    Process exec 601 530 768 2300 33000
    Shell process create 4200 4000 4800 10000 58000
    Mmap latency 99.0 68.0 139 620 1400
    Page fault latency 1.88 1.42 2.73 12.4 26.3
    ttcp Bandwidth (Mb/s) MTU 1500 TX MTU 1500 RX MTU 500 TX MTU 500 RX
    Native Linux 897 897 602 544
    Xen 897 (-0%) 897 (-0%) 516 (-14%) 467 (-14%)
    VMware 3.2 291 (-68%) 615 (-31%) 101 (-83%) 137 (-75%)
    UML 165 (-82%) 203 (-77%) 61.1 (-90%) 91.4 (-83%)

    These results show:

    • Direct fast system call handlers in Xen achieve near-native null call and null I/O latencies (0.46 μ0.46\,\mus vs 0.45 μ0.45\,\mus on L-UP).
    • Process creation operations (fork, exec) in Xen incur a modest penalty due to batched page table validation hypercalls (198 μ198\,\mus vs 110 μ110\,\mus on L-UP), while remaining substantially faster than VMware (874 μ874\,\mus) and UML (21000 μ21000\,\mus).
    • Network page-flipping achieves zero per-byte copy overhead, saturating Gigabit Ethernet links at MTU 1500 (897 897\,Mb/s). At MTU 500, per-packet firewalling and demultiplexing introduce a 14% throughput overhead.
  12. Knowl 12 — Multi-Domain Scalability and Resource Isolation under Pathological Workloads

    empirical result

    Xen was evaluated for scalability up to 128 domains and for performance isolation under hostile, adversarial workloads on a dual-CPU 2.4 GHz server:

    • Domain Scalability: Running compute-bound SPEC CINT2000 processes across 1 to 128 concurrent domains under Xen's default 5ms scheduling slice resulted in an aggregate throughput reduction of 7.5% relative to native Linux. Increasing the scheduling slice to 50ms virtually eliminated this gap. Under full load across 128 compute-bound domains, an otherwise idle 129th domain maintained an average interactive UDP response latency of 5.4ms (standard deviation 16ms) due to Borrowed Virtual Time (BVT) warp dispatch.

    • Memory Footprint: A quiescent XenoLinux domain running standard daemons, sshd, and an Apache web server reduced its memory consumption via the balloon driver to 6.2MB (without swap) and 4.2MB (with swap). Xen maintains only 20kB of fixed hypervisor state per domain.

    • Defensive Performance Isolation: Four domains were configured with equal resource shares: two domains executed standard benchmarks (PostgreSQL OSDB-IR and SPEC WEB99), while two adversarial domains simultaneously executed disruptive workloads (a sustained disk write hog via dd combined with high-frequency small file creations, a fork bomb, and a 3GB virtual memory thrashing/allocation loop). The benchmark domains experienced only a 4% (OSDB-IR) and 2% (SPEC WEB99) reduction in throughput compared to uncontended execution. In contrast, running the same adversarial workloads on native Linux completely starved the benchmark processes, consuming nearly all CPU time within the OS.

  13. Knowl 13 — Operating System Porting Complexity and Code Modification Costs

    data/table

    Porting commodity operating systems to the paravirtualized x86 Xen architecture requires modifying architecture-dependent kernel code while leaving user-space binaries and core OS subsystems unmodified.

    OS Subsection Linux 2.4.21 (lines) Windows XP (lines)
    Architecture-independent 78 1299
    Virtual network driver 484 –
    Virtual block-device driver 1070 –
    Xen-specific (non-driver) 1363 3321
    Total 2995 4620
    Portion of total x86 code base 1.36% 0.04%

    Key porting observations include:

    • Porting Linux required 2995 lines of code (1.36% of its x86 codebase). Linux accesses page table entries through preprocessor macros, allowing paravirtualization hooks and translation hypercalls to be cleanly centralized.
    • Porting Windows XP required 4620 lines (0.04% of its codebase). XP required substantially more changes to architecture-independent code (1299 lines) because page table entries are accessed via diverse structures and unions rather than centralized macros, requiring automated script-based rewrites. XP also required modifications to accommodate 16-bit legacy emulation and bootstrap initialization.
  14. Knowl 14 — Borrowed Virtual Time Scheduling for Low-Latency Domain Dispatch

    model/method

    Xen implements the Borrowed Virtual Time (BVT) scheduling algorithm to allocate CPU time across virtual machine domains. BVT is a work-conserving, proportional-share scheduler that provides fair sharing of processor capacity based on per-domain integer weights configured via Domain0.

    To support OS subsystems that depend on timely execution (such as TCP stack round-trip time estimation, ACK generation, and timeout management), BVT implements virtual-time warping. When a domain receives an asynchronous event (e.g., packet arrival or timer trigger), BVT temporarily violates strict fair-share virtual time to immediately dispatch the woken domain with low latency. Once the warped execution allowance expires, the domain's virtual time is restored to ensure long-term proportional fairness.

  15. Knowl 15 — Limitation of Proportional Disk Scheduling under Synchronous I/O Workloads

    limitation

    While Xen's Borrowed Virtual Time (BVT) CPU scheduler accurately enforces proportional share allocations for CPU-bound and read-heavy workloads (with OSDB-IR throughput matching assigned domain weights to within 4%), Xen's storage architecture fails to achieve proportional differentiated service under workloads with heavy synchronous disk activity (such as the database transactional workload OSDB-OLTP).

    Under high synchronous write activity, domains assigned higher scheduler weights do not achieve proportionally higher disk throughput. This limitation stems from the interaction between Xen's simple round-robin domain batching and low-level elevator disk scheduling, which causes domains with synchronous write-ahead logging to underperform due to head movement and request queuing contention.

Coverage note — Omitted high-level visionary descriptions of the XenoServer planetary computing infrastructure, economic congestion pricing models, and prospective future extensions (such as the last-chance page cache and copy-on-write virtual disks), focusing on Xen's concrete hypervisor design, paravirtualized subsystem mechanisms, and empirical evaluation.

References

  1. 1.A. Awadallah and M. Rosenblum. The vMatrix: A network of virtual machine monitors for dynamic content distribution. In Proceedings of the 7th International Workshop on Web Content Caching and Distribution (WCW 2002), Aug. 2002.
  2. 2.A. Bakre and B. R. Badrinath. I-TCP: indirect TCP for mobile hosts. In Proceedings of the 15th International Conference on Distributed Computing Systems (ICDCS 1995), pages 136–143, June 1995.
  3. 3.G. Banga, P. Druschel, and J. C. Mogul. Resource containers: A new facility for resource management in server systems. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI 1999), pages 45–58, Feb. 1999.
  4. 4.A. Bavier, T. Voigt, M. Wawrzoniak, L. Peterson, and P. Gunningberg. SILK: Scout paths in the Linux kernel. Technical Report 2002-009, Uppsala University, Department of Information Technology, Feb. 2002.
  5. 5.B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer, M. Fiuczynski, D. Becker, S. Eggers, and C. Chambers. Extensibility, safety and performance in the SPIN operating system. In Proceedings of the 15th ACM SIGOPS Symposium on Operating Systems Principles, volume 29(5) of ACM Operating Systems Review, pages 267–284, Dec. 1995.
  6. 6.A. Brown and M. Seltzer. Operating System Benchmarking in the Wake of Lmbench: A Case Study of the Performance of NetBSD on the Intel x86 Architecture. In Proceedings of the 1997 ACM SIGMETRICS Conference on Measurement and Modeling of Computer Systems, June 1997.
  7. 7.E. Bugnion, S. Devine, K. Govil, and M. Rosenblum. Disco: Running commodity operating systems on scalable multiprocessors. In Proceedings of the 16th ACM SIGOPS Symposium on Operating Systems Principles, volume 31(5) of ACM Operating Systems Review, pages 143–156, Oct. 1997.
  8. 8.Connectix. Product Overview: Connectix Virtual Server, 2003. http://www.connectix.com/products/vs.html.
  9. 9.G. Czajkowski and L. Daynès. Multitasking without compromise: a virtual machine evolution. ACM SIGPLAN Notices, 36(11):125–138, Nov. 2001. Proceedings of the 2001 ACM SIGPLAN Conference on Object Oriented Programming, Systems, Languages and Applications (OOPSLA 2001).
  10. 10.S. Devine, E. Bugnion, and M. Rosenblum. Virtualization system including a virtual machine monitor for a computer with a segmented architecture. US Patent, 6397242, Oct. 1998.
  11. 11.K. J. Duda and D. R. Cheriton. Borrowed-Virtual-Time (BVT) scheduling: supporting latency-sensitive threads in a general-purpose scheduler. In Proceedings of the 17th ACM SIGOPS Symposium on Operating Systems Principles, volume 33(5) of ACM Operating Systems Review, pages 261–276, Kiawah Island Resort, SC, USA, Dec. 1999.
  12. 12.G. W. Dunlap, S. T. King, S. Cinar, M. Basrai, and P. M. Chen. ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and Replay. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 2002), ACM Operating Systems Review, Winter 2002 Special Issue, pages 211–224, Boston, MA, USA, Dec. 2002.
  13. 13.D. Engler, S. K. Gupta, and F. Kaashoek. AVM: Application-level virtual memory. In Proceedings of the 5th Workshop on Hot Topics in Operating Systems, pages 72–77, May 1995.
  14. 14.Ensim. Ensim Virtual Private Servers, 2003. http://www.ensim.com/products/materials/datasheet_vps_051003.pdf.
  15. 15.K. A. Fraser, S. M. Hand, T. L. Harris, I. M. Leslie, and I. A. Pratt. The Xenoserver computing infrastructure. Technical Report UCAM-CL-TR-552, University of Cambridge, Computer Laboratory, Jan. 2003.
  16. 16.T. Garfinkel, M. Rosenblum, and D. Boneh. Flexible OS Support and Applications for Trusted Computing. In Proceedings of the 9th Workshop on Hot Topics in Operating Systems, Kauai, Hawaii, May 2003.
  17. 17.J. Gelinas. Virtual Private Servers and Security Contexts, 2003. http://www.solucorp.qc.ca/miscprj/s_context.hc.
  18. 18.K. Govil, D. Teodosiu, Y. Huang, and M. Rosenblum. Cellular Disco: Resource management using virtual clusters on shared-memory multiprocessors. In Proceedings of the 17th ACM SIGOPS Symposium on Operating Systems Principles, volume 33(5) of ACM Operating Systems Review, pages 154–169, Dec. 1999.
  19. 19.P. H. Gum. System/370 extended architecture: facilities for virtual machines. IBM Journal of Research and Development, 27(6):530–544, Nov. 1983.
  20. 20.S. Hand. Self-paging in the Nemesis operating system. In Proceedings of the 3rd Symposium on Operating Systems Design and Implementation (OSDI 1999), pages 73–86, Oct. 1999.
  21. 21.S. Hand, T. L. Harris, E. Kotsovinos, and I. Pratt. Controlling the XenoServer Open Platform, April 2003.
  22. 22.A. Jeffrey and I. Wakeman. A Survey of Semantic Techniques for Active Networks, Nov. 1997. http://www.cogs.susx.ac.uk/projects/safetynet/.
  23. 23.M. F. Kaashoek, D. R. Engler, G. R. Granger, H. M. Bricenño, R. Hunt, D. Mazières, T. Pinckney, R. Grimm, J. Jannotti, and K. Mackenzie. Application performance and flexibility on Exokernel systems. In Proceedings of the 16th ACM SIGOPS Symposium on Operating Systems Principles, volume 31(5) of ACM Operating Systems Review, pages 52–65, Oct. 1997.
  24. 24.R. Kessler and M. Hill. Page placement algorithms for large real-indexed caches. ACM Transaction on Computer Systems, 10(4):338–359, Nov. 1992.
  25. 25.S. T. King, G. W. Dunlap, and P. M. Chen. Operating System Support for Virtual Machines. In Proceedings of the 2003 Annual USENIX Technical Conference, Jun 2003.
  26. 26.M. Kozuch and M. Satyanarayanan. Internet Suspend/Resume. In Proceedings of the 4th IEEE Workshop on Mobile Computing Systems and Applications, Calicoon, NY, Jun 2002.
  27. 27.I. M. Leslie, D. McAuley, R. Black, T. Roscoe, P. Barham, D. Evers, R. Fairbairns, and E. Hyden. The design and implementation of an operating system to support distributed multimedia applications. IEEE Journal on Selected Areas In Communications, 14(7):1280–1297, Sept. 1996.
  28. 28.J. MacKie-Mason and H. Varian. Pricing congestible network resources. IEEE Journal on Selected Areas In Communications, 13(7):1141–1149, Sept. 1995.
  29. 29.L. McVoy and C. Staelin. lmbench: Portable tools for performance analysis. In Proceedings of the USENIX Annual Technical Conference, pages 279–294, Berkeley, Jan. 1996. Usenix Association.
  30. 30.J. Navarro, S. Iyer, P. Druschel, and A. Cox. Practical, transparent operating system support for superpages. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 2002), ACM Operating Systems Review, Winter 2002 Special Issue, pages 89–104, Boston, MA, USA, Dec. 2002.
  31. 31.G. C. Necula. Proof-carrying code. In Conference Record of POPL 1997: The 24th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 106–119, Jan. 1997.
  32. 32.S. Oikawa and R. Rajkumar. Portable RK: A portable resource kernel for guaranteed and enforced timing behavior. In Proceedings of the IEEE Real Time Technology and Applications Symposium, pages 111–120, June 1999.
  33. 33.L. Peterson, D. Culler, T. Anderson, and T. Roscoe. A blueprint for introducing disruptive technology into the internet. In Proceedings of the 1st Workshop on Hot Topics in Networks (HotNets-I), Princeton, NJ, USA, Oct. 2002.
  34. 34.I. Pratt and K. Fraser. Arsenic: A user-accessible gigabit ethernet interface. In Proceedings of the Twentieth Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM-01), pages 67–76, Los Alamitos, CA, USA, Apr. 22–26 2001. IEEE Computer Society.
  35. 35.D. Reed, I. Pratt, P. Menage, S. Early, and N. Stratford. Xenoservers: accounted execution of untrusted code. In Proceedings of the 7th Workshop on Hot Topics in Operating Systems, 1999.
  36. 36.J. S. Robin and C. E. Irvine. Analysis of the Intel Pentium's ability to support a secure virtual machine monitor. In Proceedings of the 9th USENIX Security Symposium, Denver, CO, USA, pages 129–144, Aug. 2000.
  37. 37.C. P. Sapuntzakis, R. Chandra, B. Pfaff, J. Chow, M. S. Lam, and M. Rosenblum. Optimizing the Migration of Virtual Computers. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 2002), ACM Operating Systems Review, Winter 2002 Special Issue, pages 377–390, Boston, MA, USA, Dec. 2002.
  38. 38.L. Seawright and R. MacKinnon. VM/370 – a study of multiplicity and usefulness. IBM Systems Journal, pages 4–17, 1979.
  39. 39.P. Shenoy and H. Vin. Cello: A Disk Scheduling Framework for Next-generation Operating Systems. In Proceedings of ACM SIGMETRICS'98, the International Conference on Measurement and Modeling of Computer Systems, pages 44–55, June 1998.
  40. 40.V. Sundaram, A. Chandra, P. Goyal, P. Shenoy, J. Sahni, and H.M.Vin. Application Performance in the QLinux Multimedia Operating System. In Proceedings of the 8th ACM Conference on Multimedia, Nov. 2000.
  41. 41.D. Tennenhouse. Layered Multiplexing Considered Harmful. In Rudin and Williamson, editors, Protocols for High-Speed Networks, pages 143–148. North Holland, 1989.
  42. 42.C. A. Waldspurger. Memory resource management in VMware ESX server. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 2002), ACM Operating Systems Review, Winter 2002 Special Issue, pages 181–194, Boston, MA, USA, Dec. 2002.
  43. 43.A. Whitaker, M. Shaw, and S. D. Gribble. Denali: Lightweight Virtual Machines for Distributed and Networked Applications. Technical Report 02-02-01, University of Washington, 2002.
  44. 44.A. Whitaker, M. Shaw, and S. D. Gribble. Scale and performance in the Denali isolation kernel. In Proceedings of the 5th Symposium on Operating Systems Design and Implementation (OSDI 2002), ACM Operating Systems Review, Winter 2002 Special Issue, pages 195–210, Boston, MA, USA, Dec. 2002.

Citation

MLA
Barham, P., et al. “Xen and the Art of Virtualization”. Proceedings of the Nineteenth ACM Symposium on Operating Systems Principles, 2003, pp. 164–77, https://doi.org/10.1145/945445.945462.
APA
Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer, R., Pratt, I., & Warfield, A. (2003). Xen and the art of virtualization. Proceedings of the Nineteenth ACM Symposium on Operating Systems Principles, 164–177. https://doi.org/10.1145/945445.945462
Chicago
Barham, P., B. Dragovic, K. Fraser, et al. 2003. “Xen and the Art of Virtualization”. Proceedings of the Nineteenth ACM Symposium on Operating Systems Principles, 164–77. https://doi.org/10.1145/945445.945462.
Harvard
Barham, P. et al. (2003) “Xen and the art of virtualization”, Proceedings of the nineteenth ACM symposium on Operating systems principles. ACM, pp. 164–177. Available at: https://doi.org/10.1145/945445.945462.
Vancouver
1. Barham P, Dragovic B, Fraser K, Hand S, Harris T, Ho A, Neugebauer R, Pratt I, Warfield A (2003) Xen and the art of virtualization. In: Proceedings of the nineteenth ACM symposium on Operating systems principles. ACM, pp 164–177

BibTeX

@inproceedings{Barham_2003, series={SOSP03}, title={Xen and the art of virtualization}, url={http://dx.doi.org/10.1145/945445.945462}, DOI={10.1145/945445.945462}, booktitle={Proceedings of the nineteenth ACM symposium on Operating systems principles}, publisher={ACM}, author={Barham, Paul and Dragovic, Boris and Fraser, Keir and Hand, Steven and Harris, Tim and Ho, Alex and Neugebauer, Rolf and Pratt, Ian and Warfield, Andrew}, year={2003}, month=Oct, pages={164–177}, collection={SOSP03} }
Metadata:Crossref

Source Code

This paper has an official code repository available. Click below to access the source code.

View Repository

Access the Paper

This paper is available from its original source. Click below to access the PDF.

Open PDF