Jump to: navigation, search


Installing XenServer on Virtual Box

This is a really useful development environment when you want everything running on a single box.

The setup includes:

  • Virtual Box on your laptop or desktop
    • Note Virtual box runs well on many platforms: Linux, MacOS X and Windows
  • XenServer running in a Virtual Box VM
  • OpenStack running in a VM on XenServer
  • Launching a VM on XenServer using OpenStack

Install Virtual Box

You can get Virtual Box from your favourite package manager, or from here: https://www.virtualbox.org/wiki/Downloads

Xen requires a 64-bit CPU, so make sure that you install, on a 64-bit operating system, the 64-bit version of Virtual Box


As with any XenServer + OpenStack + DevStack deployment, it is worth getting your head straight around the networking.

While there are many options that could work, please try the recommended approach first. It will really help you understand what is possible.

The XenServer VM running on Virtual Box:

  • a single bridged adapter onto your primary network
    • NAT is default, but not as useful
    • This will make XenServer appear on your network
  • the above network is assumed to have DHCP (like that provided by a home router)

The Ubuntu VM running on XenServer:

  • Always gets four interfaces
    • eth0: private networking with the XenServer, best to ignore this one
    • eth1: VM traffic network
    • eth2: management network (rabbit, mysql, keystone, etc)
    • eth3: public network (floating ip traffic, external access to APIs)

For a nice picture see the official docs: http://docs.openstack.org/folsom/openstack-compute/admin/content/introduction-to-xen.html#xenapi-deployment-architecture

Installing XenServer

First download the XenServer ISO onto the machine running virtual box from the XenServer download site

Once complete you need to create a Virtual Box VM with:

  • cd drive attached to the XenServer ISO
  • a bridged network interface onto a network
    • you will need "Promiscuous Mode" at "Allow All" on the NIC to ensure the traffic for VMs running inside the XenServer VM will be allowed
    • ideally with a DHCP server and an internet connection (just like most home router networks)
  • More than 2GB RAM (Dom0 takes 800MB, DomU takes 1GB+ and then some RAM needed to start VMs)
  • enable the following motherboard options:
    • Enable IO APIC
    • Hardware clock in UTC
  • enable the following processor and Acceleration options:
    • PAE, VT-x, Nested Paging
  • Add a single hard disk of at least 50 GB
  • Audio and USB can be disabled

Now you have the VM, start up the VM and you should go into the XenServer installer:

  • Ensure you select "XenServer optimised" storage when prompted
  • Configure the networking as you desire, but a static address in the same subnet as your host machine is best
  • Remove the ISO from the VM's cd drive, when requested

Running DevStack on the XenServer VM

If everything has gone to plan, you should now have a working XenServer server in a Virtual Box VM, running on your PC. Moreover, that XenServer server should be able to connect to the internet.

We are now ready to configure and run the xen tools part of DevStack. This will create an Ubuntu VM, and run stack.sh when the VM boots, and install and configure the latest OpenStack code in that VM. We now follow the instructions from the DevStack XenServer ReadMe: https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md

Getting DevStack downloaded onto XenServer's Dom0

At this stage you can ssh into the XenServer box. You are now on "Dom0", the XenServer control VM. It is worth adding your SSH key as an authorized key, in the usual way, to make this easier. DevStack will also copy that configuration into the DevStack VM. Ideally also create a new SSH key, and authorize that too, to enable the DevStack script to access the VM it creates.

Now we can follow step 2 of the Readme:

Configuring DevStack

The tricky part of configuration is the Network configuration. Lets step through all of the example configuration options, and add a few extras that will help in this particular case. The following should be added to a file called "localrc" in the devstack directory, remembering to check each option and update it (at least the IP and passwords must be changed)

# At the moment, we depend on github's snapshot function.

# Passwords
# NOTE: these need to be specified, otherwise devstack will try
# to prompt for these passwords, blocking the install process.

# This will be the password for the [[OpenStack]] VM (both stack and root users)

# XenAPI parameters
# NOTE: The following must be set to your XenServer root password!


# Explicitly set virt driver

# Explicitly enable multi-host for nova-network HA

# Give extra time for boot

# You can change the default amount of memory if you don't have enough
# but note that swap is likely to be used, and the system therefore may run slowly.
# Increased the disk size

# Keep any code changes I make

# Turn on logging

# Default image doesn't have an agent
# this will speed up the instance boot time

Running DevStack

No we have everything configured, we can run the script that will:

  • Create the Ubuntu VM (via a network install)
  • Download DevStack into that VM, and install the XenServer tools
  • Finally boots up the VM and runs stack.sh during the boot process

To run this script type the following on the XenServer box:

# assumes you are at the root of the devstack source
cd tools/xen

If you need to change settings related to when the DomU is created (like PUB_IP, and OSDOMU_MEM_MB), you will need to delete the template before, otherwise your changes will not take affect. You can do this by using the following setting:


Monitoring progress of install_os_domU.sh

The most lengthy part of the process is doing the network install of Ubuntu. To monitor the progress of this, you are best accessing the VNC console of the VM, and seeing how the install is progressing.

You can tell that the Ubuntu install has succeeded once a template has been created, and the new DevStackOSDomU VM has been created. If SSH keys were installed into the DomU, the script will log into the DomU, and tail the content of /opt/stack/run.sh.log on the VM. If no ssh keys are install you can look at this yourself.

What is inside the Ubuntu DomU VM?

First log into the Ubuntu VM that was created. Note:

  • user is called "stack"
  • root user is also enabled
  • the password is specified in the localrc file.

Note the following lines:

# This is the password for your guest (for both stack and root users)

Once you log in as the stack user (possibly via the ssh keys that may have been installed), you are in /opt/stack. In here you can see all the OpenStack code that has been installed using "python setup.py develop".

Using OpenStack

The best way to get started is to take a look at the dashboard which you can access at http://<ip_address_of_ubuntu_vm>

By default, two users are created "demo" and "admin", with an appropriate set of projects. The password used for both accounts is the ADMIN_PASSWORD specified in localrc:


Changing the configuration to use XenAPI NFS

Here is a good example of how to use Cinder with XenServer in some simple deployments.

First install NFS server on your machine: https://help.ubuntu.com/community/SettingUpNFSHowTo

Here is an example /etc/exports file:

/export *(rw,sync,no_subtree_check,all_squash)

Then you can update the localrc file to use NFS, and reboot the VM to use the new settings:


Changing some code

There is one other use for the NFS server we have just installed. We can now access the above code from your development machine, and directly edit it. Lets look at changing Nova.

We can edit the /etc/exports file, and restart the NFS server and expose the /opt/stack directory. Here is the /etc/exports file that should do the trick:

/export *(rw,sync,no_subtree_check,all_squash)

You can then mount /opt/stack in the usual way on your dev box. You will find, although with a bit of lag, git will still work using the keys and settings local to your dev box.

It may be desirable to instead mount some of your source files inside the nova VM, but for ease of getting the source files in the first place, I have documented the alternative.