Difference between revisions of "XenServer/XenAndXenServer"
(first dump from manuals) |
m (Bob Ball moved page XenServer/XenXCPAndXenServer to XenServer/XenAndXenServer) |
||
| (12 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | = Getting Started = | |
| − | |||
| − | |||
| − | = | + | To get started, take a look at: [[XenServer/GettingStarted|Getting started with XenServer and OpenStack]] |
| + | |||
| + | = Official Docs = | ||
| − | + | You can find this information in the official docs: | |
| + | http://docs.openstack.org/trunk/openstack-compute/admin/content/introduction-to-xen.html | ||
= Introduction to using Xen, XCP and [[XenServer]] with [[OpenStack]] = | = Introduction to using Xen, XCP and [[XenServer]] with [[OpenStack]] = | ||
| + | |||
In this section we will describe Xen, XCP, and [[XenServer]], the | In this section we will describe Xen, XCP, and [[XenServer]], the | ||
differences between them, and how to use them with [[OpenStack]]. Xen's | differences between them, and how to use them with [[OpenStack]]. Xen's | ||
| Line 16: | Line 18: | ||
=== Xen === | === Xen === | ||
| − | Xen is a hypervisor. It provides the | + | Xen is a hypervisor. It provides the fundamental isolation between virtual machines. Xen is open source (GPLv2) and is managed by Xen.org, an cross-industry organization. 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. |
| − | fundamental isolation between virtual machines. Xen is open source (GPLv2) | ||
| − | and is managed by Xen.org, an cross-industry organization. | ||
| − | 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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
=== Citrix [[XenServer]] === | === Citrix [[XenServer]] === | ||
| − | Citrix [[XenServer]] is a commercial | + | Citrix [[XenServer]] is a commercial product. It is based on XCP, and exposes the same toolstack and managment API. As an analogy, think of [[XenServer]] being based on XCP in the way that Red Hat Enterprise Linux is based on Fedora. [[XenServer]] has a free version (which is very similar to XCP) and paid-for versions with additional features enabled. |
| − | product. It is based on XCP, and exposes the same toolstack and managment | ||
| − | API. As an analogy, think of [[XenServer]] being based on XCP in the way that Red | ||
| − | Hat Enterprise Linux is based on Fedora. [[XenServer]] has a free version (which | ||
| − | is very similar to XCP) and paid-for versions with additional features | ||
| − | enabled. | ||
=== xapi / XAPI / XenAPI === | === xapi / XAPI / XenAPI === | ||
| − | Both [[XenServer]] and XCP include Xen, Linux, and the primary control | + | Both [[XenServer]] and XCP include Xen, Linux, and the primary control daemon known as xapi. |
| − | daemon known as xapi. | ||
| − | The API shared between XCP and [[XenServer]] is called ""XenAPI"". [[OpenStack]] usually refers to XenAPI, to | + | The API shared between XCP and [[XenServer]] is called ""XenAPI"". [[OpenStack]] usually refers to XenAPI, to indicate that the integration works equally well on XCP and [[XenServer]]. Sometimes, a careless person will refer to [[XenServer]] specifically, but you can be reasonably confident that anything that works on [[XenServer]] will also work on the latest version of XCP. |
| − | indicate that the integration works equally well on XCP and [[XenServer]]. | ||
| − | Sometimes, a careless person will refer to [[XenServer]] specifically, but you can | ||
| − | be reasonably confident that anything that works on [[XenServer]] will also work | ||
| − | on the latest version of XCP. | ||
== Privileged and unprivileged domains == | == Privileged and unprivileged domains == | ||
| Line 65: | Line 45: | ||
There is an ongoing project to split domain 0 into multiple privileged | There is an ongoing project to split domain 0 into multiple privileged | ||
| − | domains known as | + | domains known as ""driver domains"" and <emphasis |
| − | role="bold">stub domains | + | role="bold">stub domains"". This would give even better separation |
between critical components. This is an ongoing research project and you | between critical components. This is an ongoing research project and you | ||
shouldn't worry about it right now. The current architecture just has three | shouldn't worry about it right now. The current architecture just has three | ||
| Line 74: | Line 54: | ||
== Paravirtualized versus hardware virtualized domains == | == Paravirtualized versus hardware virtualized domains == | ||
| − | A Xen virtual machine can be | + | A Xen virtual machine can be ""paravirtualized |
| − | (PV) | + | (PV)"" or ""hardware virtualized |
| − | (HVM) | + | (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 | 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 | virtualized and will co-operate with Xen and domain 0; this gives them better | ||
| Line 86: | Line 66: | ||
In [[OpenStack]], customer VMs may run in either PV or HVM mode. However, | In [[OpenStack]], customer VMs may run in either PV or HVM mode. However, | ||
the [[OpenStack]] domU (that's the one running nova-compute) <emphasis | the [[OpenStack]] domU (that's the one running nova-compute) <emphasis | ||
| − | role="bold">must | + | role="bold">must"" be running in PV mode. |
= Deployment architecture = | = Deployment architecture = | ||
| Line 93: | Line 73: | ||
similar to this: | similar to this: | ||
| − | + | [[Image:XenServer-dom0-domU.png]] | |
Key things to note: | Key things to note: | ||
| − | + | * The hypervisor: Xen | |
| − | + | * Domain 0: runs xapi and some small pieces from [[OpenStack]] (some xapi plugins and network isolation rules). The majority of this is provided by [[XenServer]] or XCP (or yourself using Kronos). | |
| − | + | * [[OpenStack]] domU: The nova-compute code runs in a paravirtualized virtual machine, running on the host under management. Each host runs a local instance of nova-compute. It will often also be running nova-network (depending on your network mode). In this case, nova-network is managing the addresses given to the tenant VMs through DHCP. | |
| − | + | * Nova uses the XenAPI Python library to talk to xapi, and it uses the Host Internal Management Network to reach from the domU to dom0 without leaving the host. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Some notes on the networking: | Some notes on the networking: | ||
| + | * The above diagram assumes FlatDHCP networking (the DevStack default). | ||
| + | * There are three main [[OpenStack]] networks: Management traffic (RabbitMQ, MySQL, etc), Tenant network traffic (controlled by nova-network) and Public traffic (floating IPs, public API end points). | ||
| + | * Each network that leaves the host has been put through a separate physical network interface. This is the simplest model, but it's not the only one possible. You may choose to isolate this traffic using VLANs instead, for example. | ||
| + | * nova-compute generally talks to [[XenServer]] using a host local private network called either "Guest Installer Network" or "Host Internal Managmenet Network". | ||
| − | + | Another example of how to deploy [[OpenStack]] on a system with only two physical network interfaces is: | |
| − | |||
| − | |||
| − | + | [[File:DevStackDiagram.png]] | |
| − | |||
| − | |||
| − | |||
| − | + | == [[XenServer]] pools == | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Before [[OpenStack]] 2012.1 ("Essex"), all [[XenServer]] machines used with | |
| + | [[OpenStack]] are standalone machines, usually only using local storage. | ||
| − | + | However in 2012.1 and later, the host-aggregates feature allows you to | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
create pools of [[XenServer]] hosts (configuring shared storage is still an out of | create pools of [[XenServer]] hosts (configuring shared storage is still an out of | ||
band activity). This move will enable live migration when using shared | band activity). This move will enable live migration when using shared | ||
| − | storage. | + | storage. |
| − | + | == Xen and libvirt == | |
| − | + | It may possible to manage Xen using libvirt. This would be necessary | |
| − | |||
| − | |||
| − | |||
for any Xen-based system that isn't using the XCP toolstack, such as SUSE | for any Xen-based system that isn't using the XCP toolstack, such as SUSE | ||
Linux or Oracle Linux. Unfortunately, this is not well tested or supported | Linux or Oracle Linux. Unfortunately, this is not well tested or supported | ||
today, and using the XCP or [[XenServer]] toolstacks with the [[OpenStack]] XenAPI | today, and using the XCP or [[XenServer]] toolstacks with the [[OpenStack]] XenAPI | ||
| − | backend is the only recommended method. | + | backend is the only recommended method. |
| − | + | = Further reading = | |
| − | + | What is Xen? by Xen.org: http://xen.org/files/Marketing/WhatisXen.pdf. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | Xen Hypervisor project: http://xen.org/products/xenhyp.html. | |
| − | + | XCP project: http://xen.org/products/cloudxen.html. | |
Latest revision as of 07:22, 13 August 2013
Contents
Getting Started
To get started, take a look at: Getting started with XenServer and OpenStack
Official Docs
You can find this information in the official docs: http://docs.openstack.org/trunk/openstack-compute/admin/content/introduction-to-xen.html
Introduction to using Xen, XCP and XenServer with OpenStack
In this section we will describe Xen, XCP, and XenServer, the differences between them, and how to use them with OpenStack. Xen's architecture is different from KVM's in important ways, and we discuss those differences and when each might make sense in your OpenStack cloud.
Basic terminology
Xen
Xen is a hypervisor. It provides the fundamental isolation between virtual machines. Xen is open source (GPLv2) and is managed by Xen.org, an cross-industry organization. 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.
Citrix XenServer
Citrix XenServer is a commercial product. It is based on XCP, and exposes the same toolstack and managment API. As an analogy, think of XenServer being based on XCP in the way that Red Hat Enterprise Linux is based on Fedora. XenServer has a free version (which is very similar to XCP) and paid-for versions with additional features enabled.
xapi / XAPI / XenAPI
Both XenServer and XCP include Xen, Linux, and the primary control daemon known as xapi.
The API shared between XCP and XenServer is called ""XenAPI"". OpenStack usually refers to XenAPI, to indicate that the integration works equally well on XCP and XenServer. Sometimes, a careless person will refer to XenServer specifically, but you can be reasonably confident that anything that works on XenServer will also work on the latest version of XCP.
Privileged and unprivileged domains
A Xen host will run 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 are known as a "domU" or "guest". All customer VMs are unprivileged of course, but you should note that on Xen the OpenStack control software (nova-compute) also runs in a domU. This gives a level of security isolation between the privileged system software and the OpenStack sofware (much of which is customer-facing). This architecture is described in more detail later.
There is an ongoing project to split domain 0 into multiple privileged domains known as ""driver domains"" and <emphasis role="bold">stub domains"". This would give even better separation between critical components. This is an ongoing research project and you shouldn't worry about it right now. The current architecture just has three levels of separation: dom0, the OpenStack domU, and the completely unprivileged customer VMs.
Paravirtualized versus hardware virtualized domains
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 have the advantage that there is no 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) <emphasis role="bold">must"" be running in PV mode.
Deployment architecture
When you deploy OpenStack on XCP or XenServer you will get something similar to this:
Key things to note:
- The hypervisor: Xen
- Domain 0: runs xapi and some small pieces from OpenStack (some xapi plugins and network isolation rules). The majority of this is provided by XenServer or XCP (or yourself using Kronos).
- OpenStack domU: The nova-compute code runs in a paravirtualized virtual machine, running on the host under management. Each host runs a local instance of nova-compute. It will often also be running nova-network (depending on your network mode). In this case, nova-network is managing the addresses given to the tenant VMs through DHCP.
- Nova uses the XenAPI Python library to talk to xapi, and it uses the Host Internal Management Network to reach from the domU to dom0 without leaving the host.
Some notes on the networking:
- The above diagram assumes FlatDHCP networking (the DevStack default).
- There are three main OpenStack networks: Management traffic (RabbitMQ, MySQL, etc), Tenant network traffic (controlled by nova-network) and Public traffic (floating IPs, public API end points).
- Each network that leaves the host has been put through a separate physical network interface. This is the simplest model, but it's not the only one possible. You may choose to isolate this traffic using VLANs instead, for example.
- nova-compute generally talks to XenServer using a host local private network called either "Guest Installer Network" or "Host Internal Managmenet Network".
Another example of how to deploy OpenStack on a system with only two physical network interfaces is:
XenServer pools
Before OpenStack 2012.1 ("Essex"), all XenServer machines used with OpenStack are standalone machines, usually only using local storage.
However in 2012.1 and later, the host-aggregates feature allows you to create pools of XenServer hosts (configuring shared storage is still an out of band activity). This move will enable live migration when using shared storage.
Xen and libvirt
It may possible to manage Xen using libvirt. This would be necessary for any Xen-based system that isn't using the XCP toolstack, such as SUSE Linux or Oracle Linux. Unfortunately, this is not well tested or supported today, and using the XCP or XenServer toolstacks with the OpenStack XenAPI backend is the only recommended method.
Further reading
What is Xen? by Xen.org: http://xen.org/files/Marketing/WhatisXen.pdf.
Xen Hypervisor project: http://xen.org/products/xenhyp.html.
XCP project: http://xen.org/products/cloudxen.html.
