Multi-tenant infrastructure
Keep tenant, service, and operator responsibilities visible on shared estates.
Solution Area
Open virtualization for cloud and infrastructure platforms.
Open infrastructure starts with an open virtualization layer. Xen gives operators an inspectable hypervisor for guest isolation, hardware ownership, control domains, and long-term platform sustainability.
Infrastructure layers
Services
Cloud workloads
Infrastructure workloads remain subject to operator-owned control and lifecycle decisions.
- Web services
- Databases
- AI workers
- Network functions
Guests
Virtual machines
Diverse guest systems keep tenant, service, appliance, and build lifecycles distinct.
- Linux VM
- Windows VM
- Appliance VM
- Build agents
Virtualization boundary
Xen hypervisor
Guest isolation, scheduling, device ownership, and control domains stay explicit.
Owned infrastructure
Hardware
Compute, memory, storage, networking, and accelerators remain operator-owned decisions.
- Compute
- Storage
- Networking
- Accelerators
Xen gives infrastructure teams a visible boundary between cloud workloads, virtual machines, the hypervisor, and owned hardware.
Infrastructure ownership
Modern infrastructure still depends on a well-defined virtualization layer.
Public clouds, private clouds, hosting providers, edge sites, enterprise estates, and research clusters all need a place where hardware, guests, tenants, and operators can be reasoned about separately.
Private and public cloud
Choose a foundation teams can inspect, govern, and sustain in the open.
Hosting and edge platforms
Keep lifecycle, hardware, network, and guest ownership choices explicit.
Long-lived estates
Evaluate a foundation for platforms that evolve over years.
Why a dedicated hypervisor?
A focused layer for isolation, ownership, and platform control.
Xen gives operators a hypervisor layer for guest isolation, hardware ownership, and platform control without treating one guest operating system as the whole platform.
A visible boundary
Xen gives operators an explicit place to reason about isolation and control.
Control domains
Hardware-facing control and management responsibilities stay part of the platform architecture.
Inspectable architecture
Source, governance, development process, and project infrastructure are public evaluation inputs.
Technical capabilities
Capabilities for owning the platform boundary
Evaluate Xen and surrounding tooling for hardware ownership, guest lifecycle, and operational control.
PCI passthrough
Assign selected devices directly to guests when infrastructure design requires clear hardware ownership.
SR-IOV
Support I/O designs that expose virtual functions while keeping ownership visible.
NUMA awareness
Treat placement and resource locality as platform design choices.
VM migration through platform tooling
XAPI-based systems document VM migration and pool capabilities.
Control domains
Represent management, device, and platform-control responsibilities explicitly.
Hardware virtualization support
Run guest systems on hardware virtualization features while preserving platform control.
Flexible scheduling
Treat CPU allocation and scheduling policy as infrastructure design concerns.
Guest isolation
Separate guests from each other and from hardware-facing responsibilities.
Scalable VM management
Use XAPI and XCP-ng for APIs, host pools, and VM lifecycle operations above Xen.
Where Xen fits
A virtualization foundation for operators and platform builders.
Xen fits where teams need to keep guests, infrastructure hardware, and management responsibilities under a visible platform model.
Public cloud foundations
Private cloud
Enterprise virtualization
Hosting providers
Edge infrastructure
Research and lab infrastructure
Network appliances
Open Xen infrastructure ecosystem
A Xen-centered ecosystem for infrastructure platforms.
Xen is the open foundation. XAPI is the Xen Project toolstack and management layer for Xen-based platforms. XCP-ng packages Xen and XAPI into a complete open platform, while commercial offerings and services can build on the same foundation.
Xen-centered ecosystem
Built on Xen
Platforms and services
XCP-ng, operations tooling, and commercial services occupy distinct roles above one foundation.
- XCP-ng
- Operations tooling
- Commercial services
Xen Project tooling
XAPI management toolstack
XAPI manages VM lifecycle, pools, and migration for Xen-based platforms.
- VM lifecycle
- Pools
- Migration
Virtualization foundation
Xen hypervisor
Xen provides the open hypervisor boundary the ecosystem builds on.
- Isolation
- Scheduling
- Device ownership
Infrastructure estate
Hardware
Servers, storage, networks, and accelerators remain operator-owned inputs.
- CPU
- Memory
- I/O
Infrastructure platforms can build above XAPI while Xen remains the open foundation on owned hardware.
Foundation
Explore the hypervisor Xen Hypervisor
The open foundation that defines the boundary between guests, control domains, and hardware.
Xen Project toolstack
Explore XAPI XAPI
A management layer and toolstack for Xen-based platforms.
Complete platform
Explore XCP-ng XCP-ng
A complete open virtualization platform built on Xen and XAPI.
Support options
View members Commercial ecosystem
Products and services from ecosystem members can build on the same open foundation.
Why architects choose Xen
Evaluation starts with ownership, openness, and maintainability.
Infrastructure teams need a project model they can inspect, sustain, and build around.
Infrastructure ownership
Operators can evaluate guests, management domains, and owned hardware together.
Open governance
Public governance and contribution paths reduce single-vendor dependency.
Inspectable source
Review source, releases, and public engineering activity before depending on the foundation.
Security response process
Security reporting and response expectations are documented for users, vendors, and contributors.
Long-lived maintainability
An open project model supports long review and update cycles.
Member-funded ecosystem
Membership helps sustain shared infrastructure, events, trademarks, and coordination.
Open governance and project health
A project process infrastructure teams can inspect.
Governance, security handling, CI resources, releases, and contribution paths are public evaluation inputs.
Linux Foundation stewardship
Xen is organized as a Linux Foundation project with visible governance.
Public CI resources
Testing resources and CI status make project infrastructure visible.
Releases and downloads
Release artifacts and download links support evaluation and development.
Documentation and contribution
Documentation, mailing lists, and contribution paths are available for deeper review.
Related resources
Follow the evaluation path from architecture to participation.
Use these project, technology, documentation, and membership entry points to continue evaluating Xen.
Hypervisor
Start with the core Xen hypervisor project.
XAPI
Explore the Xen Project management toolstack.
XCP-ng
Review the complete open platform built on Xen and XAPI.
Downloads
Find Xen releases for evaluation and development.
Documentation and wiki
Use the project wiki for deeper technical documentation.
Architecture
See how Xen fits between hardware, guests, and control.
Isolation & security
Review isolation and security resources for Xen-based platforms.
Governance
Understand the project model, roles, and governance process.
Become a member
Support shared project infrastructure and ecosystem coordination.
Next step
Evaluate the boundary, then choose the platform path.
Start with Xen architecture, review XCP-ng for a complete platform path, or join the public project work.
Infrastructure ownership
Build infrastructure on a virtualization boundary you can inspect.
Use architecture resources, XCP-ng, documentation, contribution paths, and membership to evaluate and support the open foundation.