openstack-manuals/doc/config-reference/compute/section_introduction-to-xen.xml
Mate Lakat dd8e44ae30 XenAPI: Remove warning message
After the cleanup changes, the warning message is no longer valid, thus
removing it.

Change-Id: I1f4b5bfbb32ef5b9fe6c7d0f9791f0de94992091
2014-12-16 13:58:42 +01:00

274 lines
12 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<section xmlns="http://docbook.org/ns/docbook"
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink"
version="5.0"
xml:id="introduction-to-xen">
<?dbhtml stop-chunking?>
<title xml:id="introduction-to-xen.title">Xen, XAPI, XenServer</title>
<para>
This section describes XAPI managed hypervisors, and how to
use them with OpenStack.
</para>
<section xml:id="basic-terminology">
<title>Terminology</title>
<section xml:id="terminology-xen">
<title>Xen</title>
<para>
A hypervisor that provides the fundamental isolation between
virtual machines. Xen is open source (GPLv2) and is managed by
Xen.org, a cross-industry organization and a Linux
Foundation Collaborative project.
</para>
<para>
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.
</para>
</section>
<section xml:id="terminology-xapi">
<title>XAPI</title>
<para>
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
<link
xlink:href="http://docs.vmd.citrix.com/XenServer/6.2.0/1.0/en_gb/sdk.html#object_model_overview" >
XenAPI Object Model Overview
</link>
for definitions of XAPI specific terms such as SR, VDI, VIF
and PIF.
</para>
<para>
OpenStack has a compute driver which talks to XAPI, therefore
all XAPI managed servers could be used with OpenStack.
</para>
</section>
<section xml:id="terminology-xenapi">
<title>XenAPI</title>
<para>
XenAPI is the API provided by XAPI. This name is also used by
the python library that is a client for XAPI.
</para>
</section>
<section xml:id="terminology-xenserver">
<title>XenServer</title>
<para>
An Open Source virtualization software which includes the Xen
hypervisor and XAPI for the management. For more information
and product downloads, visit
<link
xlink:href="http://xenserver.org/">
xenserver.org
</link>.
</para>
</section>
<section xml:id="privileged-and-unprivileged-domains">
<title>Privileged and unprivileged domains</title>
<para>
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
(<systemitem class="service">nova-compute</systemitem>)
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.
</para>
</section>
<section xml:id="paravirtualized-vs-hvm-domains">
<title>Paravirtualized versus hardware virtualized domains</title>
<para>
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.
</para>
<para>
In OpenStack, customer VMs may run in either PV or HVM mode.
However, the OpenStack domU (that's the one running
<systemitem class="service">nova-compute</systemitem>) must be
running in PV mode.
</para>
</section>
</section>
<section xml:id="xenapi-deployment-architecture">
<title xml:id="xenapi-deployment-architecture.title">
XenAPI deployment architecture
</title>
<para>
A basic OpenStack deployment on a XAPI-managed server, assuming
that the network provider is nova-network, looks like this:
<informalfigure>
<mediaobject>
<imageobject>
<imagedata
fileref="../../common/figures/xenserver_architecture.png"
contentwidth="140mm"/>
</imageobject>
</mediaobject>
</informalfigure>
</para>
<para>
Key things to note:
<itemizedlist>
<listitem>
<para>
The hypervisor: Xen
</para>
</listitem>
<listitem>
<para>
Domain 0: runs XAPI and some small pieces from
OpenStack, the XAPI plug-ins.
</para>
</listitem>
<listitem>
<para>
OpenStack VM: The
<systemitem class="service">Compute</systemitem>
service runs in a paravirtualized virtual machine, on
the host under management. Each host runs a local
instance of
<systemitem class="service">Compute</systemitem>.
It is also running an instance of nova-network.
</para>
</listitem>
<listitem>
<para>
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.
</para>
</listitem>
</itemizedlist>
</para>
<para>
Some notes on the networking:
<itemizedlist>
<listitem>
<para>
The above diagram assumes FlatDHCP networking.
</para>
</listitem>
<listitem>
<para>
There are three main OpenStack networks:
<itemizedlist>
<listitem>
<para>
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.
</para>
</listitem>
<listitem>
<para>
Tenant network: controlled by
nova-network, this is used for tenant
traffic.
</para>
</listitem>
<listitem>
<para>
Public network: floating IPs, public API
endpoints.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
<listitem>
<para>
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.)
</para>
</listitem>
</itemizedlist>
</para>
</section>
<section xml:id="further-reading">
<title>Further reading</title>
<para>
Here are some of the resources available to learn more
about Xen:
<itemizedlist>
<listitem>
<para>
Citrix XenServer official documentation:
<link
xlink:href="http://docs.vmd.citrix.com/XenServer/6.2.0/1.0/en_gb/">
http://docs.vmd.citrix.com/XenServer
</link>
</para>
</listitem>
<listitem>
<para>
What is Xen? by Xen.org:
<link
xlink:href="http://xen.org/files/Marketing/WhatisXen.pdf">
http://xen.org/files/Marketing/WhatisXen.pdf
</link>
</para>
</listitem>
<listitem>
<para>
Xen Hypervisor project:
<link
xlink:href="http://www.xenproject.org/developers/teams/hypervisor.html">
http://www.xenproject.org/developers/teams/hypervisor.html
</link>
</para>
</listitem>
<listitem>
<para>
Xapi project:
<link
xlink:href="http://www.xenproject.org/developers/teams/xapi.html">
http://www.xenproject.org/developers/teams/xapi.html
</link>
</para>
</listitem>
<listitem>
<para>
Further XenServer and OpenStack information:
<link
xlink:href="http://wiki.openstack.org/XenServer">
http://wiki.openstack.org/XenServer
</link>
</para>
</listitem>
</itemizedlist>
</para>
</section>
<xi:include href="section_xen-install.xml"/>
<xi:include href="section_compute-configure-xen.xml"/>
</section>