Jump to: navigation, search

Difference between revisions of "XenServer/VirtualBox"

Line 44: Line 44:
* cd drive attached to the XCP ISO
* cd drive attached to the XCP ISO
* a bridged network interface onto a network (ideally with a DHCP server and an internet connection, just like most home networks)
* a bridged network interface onto a network (ideally with a DHCP server and an internet connection, just like most home networks)
* At least 2GB RAM
* enable the following motherboard options:  
* enable the following motherboard options:  
** Enable IO APIC
** Enable IO APIC

Revision as of 13:23, 22 January 2013

Installing XenServer / XCP 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 Linux
  • XCP running in a Virtual Box VM
  • OpenStack running in a VM on XCP
  • Launching a VM on XCP using OpenStack

Install Virtual Box

You can get virtual box here: https://www.virtualbox.org/wiki/Downloads


As with any XenServer + OpenStack + DevStack deployment, it is worth getting your head strait 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 XCP 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 XCP:

  • 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 XCP

First download the XCP ISO onto the machine running virtual box from the xen xcp 1.6 download site

Once complete you need to create a virtual box VM with:

  • cd drive attached to the XCP ISO
  • a bridged network interface onto a network (ideally with a DHCP server and an internet connection, just like most home networks)
  • At least 2GB RAM
  • 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 XCP 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 XCP VM

If everything has gone to plan, you should now have a working XCP server in a Virtual Box VM, running on your PC. Moreover, that XCP 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 XCP's Dom0

At this stage you can ssh into the XCP box. You are now on "Dom0", the XCP 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.

#!highlight bash
# Defaults taken from the Readme to stop any devstack prompts for passwords
# This is the password for your guest (for both stack and root users)
# IMPORTANT: The following must be set to your dom0 root password!
# Do not download the usual images yet!
# Explicitly set virt driver here
# Explicitly set multi-host
# Give extra time for boot
# First time Ubuntu network install params

# Here we attach the public interface
# to the network the XenServer is sitting on

# Note: ideally the ip address should match the floating ip address ranges

# Telling nova how best to contact our XenServer
# should make the VNC proxy work

# I changed the default memory because I was short on memory
# Increased the disk size

# Use Ubuntu 12.04
UBUNTU_INST_TEMPLATE_NAME="Ubuntu 12.04 (64-bit) for DevStack"

# 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.

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.