Project Zeus Fedora Spec

Summary

Project Zeus is an initiative to port XCP's XenAPI toolstack to Fedora and CentOS in order to deliver all packages that are needed to install a full XCP host, via Fedora and CentOS package managers. In a nutshell, all you will need to do get the latest version of Xen, the XenAPI toolstack and other components delivered in XCP is to execute "yum install xapi". This blueprint describes the necessary work to ensure that the XCP toolstack is included as an official feature of Fedora 17, and that it will be included in the EPEL for CentOS.

Rationale

XCP is an open server virtualization platform which provides a rich management API on top of the Xen hypervisor. Currently, XCP is delivered as a black box-style appliance. Porting the XCP toolstack to Fedora and CentOS will give users a high-level management API for their Xen virtualization hosts, and will give Fedora and CentOS users the ability to run cloud orchestration stacks (e.g. CloudStack, Eucalyptus, OpenNebula, OpenStack, etc.) on top of Xen, Xapi, and Fedora/CentOS.

User stories

• Deirdre the developer wants to modify XCP's xapi, the XenAPI management daemon. Instead of provisioning a test machine with XCP installed, and then installing the XCP SDK VM, she can now install Xapi directly on her Fedora dev machine, compile the Xapi sources from Github, and reduce her hack/build/test time.

• Crispin the CloudStack administrator wants to build a cloud. He wants to use the Xen hypervisor, but he doesn't want to have to install the XCP appliance. He can instead install CentOS, add the EPEL repository, and then install the XCP toolstack. Now his CentOS host is functionally equivalent to an XCP host.

Assumptions

This specification assumes that:

• The necessary patches to the Xen hypervisor package have been upstreamed to Fedora
• The XCP toolstack packages have been accepted into Fedora

Design

This section will give a brief explanation of the Xen virtualization model, and then describe the design of Zeus. A Xen system differs from a KVM system in that the Xen hypervisor boots first, which then boots the first trusted guest, which is known as Domain 0, or more commonly just dom0. The dom0 guest is a Linux or NetBSD system, and can be thought of as the host OS of the system. After that, dom0 can start any number of non-privileged guest domains, in either paravirtualized mode or hardware-assisted virtualization mode. XCP follows this model, and also provides a management toolstack inside dom0, which allows for easier management of a set of XCP hosts by grouping them together into resource pools.

A Zeus system will consist of a Fedora 17 or Centos 6.2 base system, with a number of components installed on top of that system which will turn it into a Xen dom0 with the XCP management toolstack installed. This will effectively turn a Fedora or CentOS host into an XCP-like host, with the same features and capabilities as a traditional XCP appliance.

Below is a list of source RPMs that the XCP team is producing for Zeus. Most these will be built into multiple binary RPMs.

• xen-4.1 (amd64): This is the Xen hypervisor package. As it stands, the Fedora packages do not install all of the Xen control libraries that a Zeus system will require. The XCP team is working with the Fedora/CentOS Xen maintainers to rectify this.
• xen-api: The XenAPI server (more commonly known as Xapi). This is the daemon that provides an XML-RPC based API for managing a pool of XCP hosts. It is responsible for controlling everything Xen-related on a host.
• xen-api-libs: Libraries and assorted helper binaries for compiling and running Xapi.
• xcp-storage-managers: XenAPI Storage Managers. This is a collection of Python scripts which the Xapi daemon uses to manage storage repositories. Currently supported storage backend types are VHD-based ext3, LVHD, and NFS, but we are working to port over other backend types as well.
• xcp-eliloader: A bootloader for EL-based distributions. This Python program takes care of doing any required modifications to guest OSs (such as loading the proper Xen frontend drivers) before they can be run in paravirtualized mode.
• blktap: This creates kernel block devices which implement virtual hard disk images entirely in user space. It is required for fast disk IO on XCP systems. blktap on Debian and Ubuntu is built as a dkms kernel module, but to comply with the strict Fedora requirement to disallow out-of-mainline Linux kernel modules, we will be working on a version of blktap that can be run completely in userspace, without requiring an out-of-tree module.

Implementation notes

None at this time

See also

Xapi Fedora feature page: https://fedoraproject.org/wiki/Features/XAPI