====== XCP-XAPI ======
**XCP-XAPI** can be installed on top of other distributions (see [[http://wiki.xenproject.org/wiki/Project_Kronos|Project Kronos]]), it includes the **Xen** hypervisor, installed at low level as the virtualization tool, with the **XAPI toolstack** used internally to manage the hypervisor.

**xe** is the command line tool used to configure and operate the Xen Cloud Platform (XCP) platform, while **xsconsole** being a TUI to do basic tasks and configuration.

It is possible to use the **XCP-ISO** distribution, but it comes on top of a CentOS system, just like Citrix's XenServer. Read the [[http://wiki.xen.org/wiki/Xen_/_XCP_/_XCP_on_Linux_Overview|Xen / XCP / XAPI Overview]] to have a detailed view about the differences that exist between those.

**XenServer** is Citrix' commercial distribution of XCP.

Various [[http://wiki.xenproject.org/wiki/XCP_Management_Tools|management tools]] are available to use on top of XAPI.

Read the [[http://wiki.xenproject.org/wiki/XCP_Beginners_Guide|XCP Beginners Guide]] for more info.

A summarized version of the whole install process is available here: [[https://7terminals.com/articles/step-by-step-guide-to-setting-up-xen-and-xenapi-xcp-on-ubuntu-12-04-and-managing-it-with-xencenter/]]
===== Installation =====

Start with the [[hypervisor:base:debian|base Debian installation as described in this wiki]].

XCP requires lspci, part of the pciutils package, if you do not have the lspci command available:
<code>
> apt-get install pciutils
</code>

Then install XCP's xapi and all its dependencies, including the Xen hypervisor.
<code>
> apt-get update
> apt-get install xcp-xapi
   select: bridge network
</code>

Later, //apt-get update && apt-get upgrade// will keep up with the latest builds.

===== Make Xen the default grub entry =====

This is optional, but highly recommended on a server configuration.
<code>
> dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
> update-grub
</code>

===== Setup Networking =====
Please refer to the [[hypervisor:base:network|Configure Networking]] section.

===== Configure Dom0 Memory =====

<wrap alert>This was not applied and seems to work correctly up to now...

Although we encounter great problems to modify this value later on, as far as our experience goes.</wrap>


You should always dedicate a fixed amount of RAM for Xen dom0.
For more details, see [[hypervisor:base:xen#Configure_Dom0_Memory|Xen - Configure Dom0 Memory]].

Here are the commands to issue:
Edit **/etc/default/grub**:
<code>
> nano /etc/default/grub

ADD:
# Xen boot parameters for all Xen boots
GRUB_CMDLINE_XEN_DEFAULT="dom0_mem=1280M,max:1280M dom0_max_vcpus=2"
</code>
<WRAP center round info 90%>
Note : On servers with huge memory, Xen kernel crash. You must set a dom0 memory limit.

Take care on Wheezy, 1024M is not enough and cause kernel crash at boot with out-of-memory message.
</WRAP>

Remember to apply the change to the grub configuration by running
<code>
> update-grub
</code>

==== Avoid memory ballooning ====

Next step is to configure the toolstack to make sure dom0 memory is never ballooned down while starting new guests:

Using the XL toolstack, you should change **/etc/xen/xl.conf**

As we are unsing XAPI, which re-uses parts of the xend toolstack, we'll modify **/etc/xen/xend-config.sxp**, changing the "dom0-min-mem" option (to "dom0-min-mem 512") and changing the "enable-dom0-ballooning" option (to "enable-dom0-ballooning no"). These options will make sure xend never takes any memory away from dom0. We'll then need to reboot the system.

<code>
> nano /etc/xen/xend-config.sxp

CHANGE:
line 208: (dom0-min-mem 1280)
line 212: (enable-dom0-ballooning no)
</code>
At this point you should **reboot** so that these changes take effect.
<code>
> reboot
</code>
===== Preparing the Toolstack =====

==== Ensure that Xen is running ====
<code>
> cat /proc/xen/capabilities
</code>
Should display “control_d”

At this stage the xcp-xapi service is **not running** as we didn't mention Xen to use it as its toolstack. Before we do this we still need to tweak some little settings in the system.
==== XAPI conflicts with XEND ====

XAPI won't start yet as trying to start the service will yield an error:
<code>
[FAIL] /var/run/xend.pid exists; xapi conflicts with xend ... failed!
</code>

You will need to disable xend from starting in order to get xcp-xapi to start.

=== Modify xend init script ===

<wrap help>On the latest install (Debian Wheezy 7.4) **/etc/init.d/xend** does not exist!</wrap>

This is done by modifying the file at **/etc/init.d/xend**. Many of the setup processes in this script still need to run, but xend itself should not start. This will be resolved in a future release. The command to resolve this is:
<code>
> sed -i -e 's/xend_start$/#xend_start/' -e 's/xend_stop$/#xend_stop/' /etc/init.d/xend
</code>


==== Disable xendomains service ====
<code>
> update-rc.d xendomains disable
</code>

This will probably yield two warnings (no further explanation on this at the moment)
<code>
insserv: warning: current start runlevel(s) (empty) of script 'xendomains' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script 'xendomains' overrides LSB defaults (0 1 6).
</code>

==== qemu keymap location preventing vncterm from starting ====

In order for vncterm to start up with a Linux VM, it needs to load the qemu keymaps however they are located in a location other than where it looks, this can be resolved with the following commands:
<code>
> ln -s /usr/share/qemu-linaro/keymaps /usr/share/qemu/keymaps
</code>
===== Defining the Toolstack =====
You can check whether xapi is running using the following command:
<code>
> service xcp-xapi status
</code>

If you are following this install process here's what you'll get:
<code>
[FAIL] Xen toolstack is not set to xapi! Exiting. ... failed! 
</code>

Set a TOOLSTACK variable to get xcp-xapi to start, you can do that with the following:
<code>
> nano /etc/default/xen

ADD:
TOOLSTACK=xapi
</code>

==== Switch between Bridge Networking and Open vSwitch modes ====
Configure xcp to use bridge networking or openswitch
<code>
> nano /etc/xcp/network.conf
</code>
REPLACE: “openvswitch” with “bridge” (or vice-versa).

==== Reboot ====

After making those changes a reboot will be needed
<code>
> reboot
</code>

----
===== Autostart a VM =====
----
It is often interesting to setup at least one VM to autostart at boot time.

Do do so you can follow this next procedure, that is also described [[http://sysadmin.compxtreme.ro/autostart-vm-in-free-version-of-xenserver-6-x/|on this post]]:

=== Gather the UUIDs of the pools you wish to auto-start ===
<code>
> xe pool-list

uuid ( RO)                : 4a187cc1-69ce-eaf3-2742-6aec0783159f
          name-label ( RW): 
    name-description ( RW): 
              master ( RO): 288efd1c-7afe-21ca-e374-cace5e2d7e20
          default-SR ( RW): 26b9d87b-f344-1c8d-c5c5-a155d4e4e2e0

</code>

=== Set the pool or server to allow auto-start ===
<code>
> xe pool-param-set uuid=4a187cc1-69ce-eaf3-2742-6aec0783159f other-config:auto_poweron=true
</code>

=== Setting the VM to auto-start ===
<code>
> xe vm-list 
uuid ( RO)           : 76868e4b-4d82-320e-dd46-41340e6a67f3
     name-label ( RW): Control domain on host: store
    power-state ( RO): running


uuid ( RO)           : b7e42681-56c1-24cc-db45-9577981000b1
     name-label ( RW): XOA 3.6 Basic
    power-state ( RO): running

> xe vm-param-set uuid=b7e42681-56c1-24cc-db45-9577981000b1 other-config:auto_poweron=true
</code>

=== Modify rc.local ===
The previous steps are documented to be enough when using Citrix's XenServer. As we're using XCP/XAPI, one supplementary step is required, having a script to start at boot time all vms with "auto_poweron" in their other-config. This can be achieved by editing the //**/etc/rc.local**// file, adding the following code:

<code>
> nano /etc/rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

[ -e /proc/xen ] || exit 0

XAPI_START_TIMEOUT_SECONDS=240

# wait for xapi to complete initialisation for a max of XAPI_START_TIMEOUT_SECONDS
/usr/lib/xcp/bin/xapi-wait-init-complete ${XAPI_START_TIMEOUT_SECONDS}

if [ $? -eq 0 ]; then

pool=$(xe pool-list params=uuid --minimal 2> /dev/null)

auto_poweron=$(xe pool-param-get uuid=${pool} param-name=other-config param-key=auto_poweron 2> /dev/null)
if [ $? -eq 0 ] && [ "${auto_poweron}" = "true" ]; then
logger "$0 auto_poweron is enabled on the pool-- this is an unsupported configuration."

# if xapi init completed then start vms (best effort, don't report errors)
xe vm-start other-config:auto_poweron=true power-state=halted --multiple >/dev/null 2>/dev/null || true
fi
fi
</code>

You can test that the code works using the following command, it is important to validate its function as line 19 may need to be adapted, i.e: YMMV for /usr/lib/xcp/bin/xapi-wait-init-complete

<code>
> /etc/rc.local
</code>

----
===== Create and Access File Based VDI from Dom0 =====
----

The following procedure is based on the one described [[http://discussions.citrix.com/topic/334905-mount-vm-disk-image-as-file-system-in-xenserver-6/|in this post]].

----
==== Create the Virtual Hard Disk (VDI) ====
----

First identifying our SR of choice, then create the file based VHD (VDI).

<code>
> xe sr-list
...
uuid ( RO)                : 26b9d87b-f344-1c8d-c5c5-a155d4e4e2e0
          name-label ( RW): X-Local-SR
    name-description ( RW): 
                host ( RO): store
                type ( RO): ext
        content-type ( RO): 
...
  
> xe vdi-create sr-uuid=26b9d87b-f344-1c8d-c5c5-a155d4e4e2e0 name-label=IPFire type=user virtual-size=5GiB
72e00fc6-98bb-48fe-ab4d-b52d1ef721b5
</code>

We'll now have a new vhd file at:\\
//**/run/sr-mount/<sr-uuid>/<vdi-uuid>.vhd**//

Which, in our example, translates to:\\
/run/sr-mount/26b9d87b-f344-1c8d-c5c5-a155d4e4e2e0/72e00fc6-98bb-48fe-ab4d-b52d1ef721b5.vhd
----
==== Create a VBD for the VDI and plug it ====
----

=== Create VBD (virtual block device) ===
The newly created VBD will link our Dom0 to the VDI we just created, first let's recover our Dom0 UUID:
<code>
> xe vm-list | grep -B 1 -e Control

uuid ( RO)           : 76868e4b-4d82-320e-dd46-41340e6a67f3
     name-label ( RW): Control domain on host: store
</code>

Then let's create and link the VBD to our Dom:
<code>
> xe vbd-create vm-uuid=76868e4b-4d82-320e-dd46-41340e6a67f3 vdi-uuid=72e00fc6-98bb-48fe-ab4d-b52d1ef721b5 device=autodetect

7472f458-ba3f-7344-99a7-6660a39037a6
</code>

=== Plug VBD ===
Finaly we'll plug the VBD, making the VDI effectively available from the Dom0:
<code>
> xe vbd-plug uuid=7472f458-ba3f-7344-99a7-6660a39037a6
</code>

At this stage, a new device will get listed under //**/dev/sm/backend/<sr-uuid>/<vdi-uuid>**// like:

Before vdb-plug instruction:
<code>
ls -l /dev/sm/backend/26b9d87b-f344-1c8d-c5c5-a155d4e4e2e0/
total 0
brw------- 1 root root 253, 0 Mar 29 01:38 4ea98b0d-b3fc-4f62-86bd-19a80f7d356b
</code>

After vdb-plug instruction:
<code>
ls -l /dev/sm/backend/26b9d87b-f344-1c8d-c5c5-a155d4e4e2e0/
total 0
brw------- 1 root root 253, 0 Mar 29 01:38 4ea98b0d-b3fc-4f62-86bd-19a80f7d356b
brw------- 1 root root 253, 1 Mar 29 01:59 72e00fc6-98bb-48fe-ab4d-b52d1ef721b5
</code>

----
==== kpartx for Mapping Partition Tables ====
----
The kpartx command creates device maps from partition tables. Each guest storage image has a partition table embedded in the file.

We'll first need to install the package if it is not already available.
<code>
> apt-get install kpartx
</code>

=== Inspect an .img file ===
kpartx lets you inspect an img file, showing its contained partitions using the -l command:
<code>
> kpartx -l /opt/xen/X-Local-ISO/<image_file_name>.img
loop0p1 : 0 122880 /dev/loop0 8192
loop0p3 : 0 1536000 /dev/loop0 131072
loop deleted : /dev/loop0
</code>
----

=== Add the partition mappings to the recognized devices in /dev/mapper/ ===
<color darkorange>**THIS DOESN'T WORK!**</color>
<code>
> kpartx -av /run/sr-mount/26b9d87b-f344-1c8d-c5c5-a155d4e4e2e0/72e00fc6-98bb-48fe-ab4d-b52d1ef721b5.vhd
</code>
==== END ====
----

++++ X11 & VNC viewer |
===== Install X11 Server & vncviewer =====

<WRAP center round important 90%>
THIS IS ONLY REQUIRED IN CASE YOU ARE WILLING TO VNC CONNECT TO YOUR RUNNING GUESTS **FROM THE HOST's COMMAND LINE**.

When installing a "regular" Xen host, the **RECOMMENDED OPTION** is to [[http://wiki.strategicz.com/vhyper/doku.php?id=hypervisor:vms:gui|install an XAPI GUI VM]]. 
</WRAP>


In order to be able to connect to the VM using VNC, we need to install the minimal tools required for graphic display:
<code>
> apt-get install xorg
</code>

Xorg isn't configured by default:
<code>
> cd /etc/X11/
> Xorg --configure
</code>

You can test to see if X11 is working by typing:
<code>
> startx
</code>
This should open an X11 session, the display should slightly change (smaller). You can make sure that you are in an X11 session by typing:
<code>
> echo $DISPLAY
</code>
That should return something like ":0". Also moving your mouse around should display a pointer.\\
It is interesting to note that it is possible to switch from the command line to the X11 session using //ctrl-alt-F4// and //ctrl-alt-F7//.

We'll finally need the vncviewer:
<code>
> apt-get install xvnc4viewer
</code>

==== Install Video Driver ====
You may have to install a specific video driver for your configuration, in case you're interested in the process and have an NVIDIA Optimus based card, you are invited to read the [[:hypervisor:base:video-driver|Video Card Driver]] section.
==== Reboot ====
All set – ready to reboot and let xcp-xapi toolstack take over
<code>
> reboot
</code>

On restart: confirm that xcp is working
<code>
> [sudo] xe vm-list
</code>
This should list the control domain
<code>
uuid ( RO) : dbcf74d2-ee50-edd5-d44d-b81fc8ba1777
name-label ( RW): Control domain on host: ubuntu-xenserver-1
power-state ( RO): running
</code>

If your output looks similar – xapi is running on the server, if you get “Connection refused”  then xapi is not setup correctly
++++