This section describes XAPI managed hypervisors, and how to use them with OpenStack.

A hypervisor that provides the fundamental isolation between virtual machines. Xen is open source (GPLv2) and is managed by XenProject.org, a cross-industry organization and a Linux Foundation Collaborative project. Xen is a component of many different products and projects. The hypervisor itself is very similar across all these projects, but the way that it is managed can be different, which can cause confusion if you're not clear which toolstack you are using. Make sure you know what toolstack you want before you get started. If you want to use Xen with libvirt in OpenStack Compute refer to .

XAPI is one of the toolstacks that could control a Xen based hypervisor. XAPI's role is similar to libvirt's in the KVM world. The API provided by XAPI is called XenAPI. To learn more about the provided interface, look at XenAPI Object Model Overview for definitions of XAPI specific terms such as SR, VDI, VIF and PIF. OpenStack has a compute driver which talks to XAPI, therefore all XAPI managed servers could be used with OpenStack.

XenAPI is the API provided by XAPI. This name is also used by the python library that is a client for XAPI.

An Open Source virtualization platform that delivers all features needed for any server and datacenter implementation including the Xen hypervisor and XAPI for the management. For more information and product downloads, visit xenserver.org .

XCP is not supported anymore. XCP project recommends all XCP users to upgrade to the latest version of XenServer by visiting xenserver.org .

This is a method for building the core packages in a XenServer installation on an existing RPM-based system. Initial support for this configuration (notably running Compute services in domain 0) was added in Havana. XenServer-core for Debian/Ubuntu is built from the main branch and, therefore, is continuously up to date.

This is a project initiated to provide the ability to install XAPI toolstack onto an existing Debian-based deployment. For more information, visit the Xen wiki wiki.xenproject.org/wiki/Project_Kronos .

A Xen host runs a number of virtual machines, VMs, or domains (the terms are synonymous on Xen). One of these is in charge of running the rest of the system, and is known as domain 0, or dom0. It is the first domain to boot after Xen, and owns the storage and networking hardware, the device drivers, and the primary control software. Any other VM is unprivileged, and is known as a domU or guest. All customer VMs are unprivileged, but you should note that on Xen, the OpenStack Compute service (nova-compute) also runs in a domU. This gives a level of security isolation between the privileged system software and the OpenStack software (much of which is customer-facing). This architecture is described in more detail later.

A Xen virtual machine can be paravirtualized (PV) or hardware virtualized (HVM). This refers to the interaction between Xen, domain 0, and the guest VM's kernel. PV guests are aware of the fact that they are virtualized and will co-operate with Xen and domain 0; this gives them better performance characteristics. HVM guests are not aware of their environment, and the hardware has to pretend that they are running on an unvirtualized machine. HVM guests do not need to modify the guest operating system, which is essential when running Windows. In OpenStack, customer VMs may run in either PV or HVM mode. However, the OpenStack domU (that's the one running nova-compute) must be running in PV mode.

A basic OpenStack deployment on a XAPI-managed server, assuming that the network provider is nova-network, looks like this: Key things to note: The hypervisor: Xen Domain 0: runs XAPI and some small pieces from OpenStack, the XAPI plug-ins. OpenStack VM: The Compute service runs in a paravirtualized virtual machine, on the host under management. Each host runs a local instance of Compute. It is also running an instance of nova-network. OpenStack Compute uses the XenAPI Python library to talk to XAPI, and it uses the Management Network to reach from the OpenStack VM to Domain 0. Some notes on the networking: The above diagram assumes FlatDHCP networking. There are three main OpenStack networks: Management network: RabbitMQ, MySQL, inter-host communication, and compute-XAPI communication. Please note that the VM images are downloaded by the XenAPI plug-ins, so make sure that the OpenStack Image service is accessible through this network. It usually means binding those services to the management interface. Tenant network: controlled by nova-network, this is used for tenant traffic. Public network: floating IPs, public API endpoints. The networks shown here must be connected to the corresponding physical networks within the data center. In the simplest case, three individual physical network cards could be used. It is also possible to use VLANs to separate these networks. Please note, that the selected configuration must be in line with the networking model selected for the cloud. (In case of VLAN networking, the physical channels have to be able to forward the tagged traffic.)

Here are some of the resources available to learn more about Xen: Citrix XenServer official documentation: http://docs.vmd.citrix.com/XenServer What is Xen? by XenProject.org: XenProject.org > Users > Cloud Xen Hypervisor project: http://www.xenproject.org/developers/teams/hypervisor.html Xapi project: http://www.xenproject.org/developers/teams/xapi.html Further XenServer and OpenStack information: http://wiki.openstack.org/XenServer