openSUSE:SUSE Studio Xen Howtos

SUSE Studio

Portal - FAQ - Howto - Support - Newsroll - API - Wishlist

Note to Xen howtos

These howtos are related to Xen DomU appliances built with SUSE Studio. Some if not all of these changes can be made automatic by scripting them.
In order to boot a DomU Xen guest you need to have a running xen hypervisor with a priviledged Dom0 xen appliance booted.
Note that Virtual Machine images built in SUSE Studio do NOT include a Swap space. It is a common practice to leave swap management up to the hypervisor.

How to start a Xen guest

Every DomU Xen guest comes from studio as a .tar.gz package that needs to be unpacked in order to start the guest. Once unpacked you will find some directory containing two files like this:

  Appliance_name-Version
  |---Appliance_name.architecture-version.raw
  |---Appliance_name.architecture-version.xenconfig

The .raw file is the disk image and can be left untouched. The .xenconfig is config for starting the guest and needs to be edited. It's content looks like this:

  #  -*- mode: python; -*-
  name="kde3.xen"
  memory=512
  disk=[ "tap:aio:Appliance_name.architecture-version,xvda,w" ]
  vif=[ "bridge=xenbr0" ]

In order to boot start the guest it is necessary to edit some of these options depending on the setup of Dom0. Basically you only need to adapt the 'disk' entry in order for xen to actually find your disk image. Another item that might need editing is 'vif' in environments where no bridged networking is used or the bridge has a different name than xenbr0. A detailed description of the items in the config file and what might have to be changed for them is described below.

!!!WARNING!!!

In many xen documentations the command "xm console" or the option "-c" with the create command are mentioned to give you access to the xenconsole. However with some recent images the console output is redirected at some point away from the xenconsole which looks to a user like the bootup hangs. This is not the case, for SLE products the following information should help getting the system running:

The boot process does in fact continue but will stop for SLE products at the license agreement that requires confirmation but is not shown on the xen console. You need to access the system with either a vncviewer or virt-viewer on the first bootup to accept the license. Once accepted the boot process continues and after it is finished a login prompt also appears on the xenconsole again. This workaround is only neccesarry for SLE products on their first boot up. See the later sections on a guide to acess the guest using vnc.

In case you can only access the guest on the xen console also on first boot up, you need to add snippet "xencons=tty" to the grub kernel command, this will then prevent a vnc login but will show all boot output including the license agreement dialogue in xenconsole. On the next boot you do not need to do this anymore as then the system will just appear the login prompt after some time also in the xenconsole.

How to change Xen guest to Citrix xva

Xen appliances built with SUSE Studio can be used also with Citrix.

The following steps illustrate how to change Xen guest to Citrix xva.

Get xva.py

wget -c http://www.xen.org/files/xva/xva.py
chmod +x xva.py
mv xva.py /usr/local/bin/

Download Build Xen Image in SuSeStudio

tar -xvf Xen_Image.i686-0.0.1.xen.tar.gz
cd Xen_Image-0.0.1/
xva.py -n Xen_Image-0.0.1 --is-pv --disk=Xen_Image.i686-0.0.1.raw --filename=Xen_Image-0.0.1.xva

Import Xen_Image-0.0.1.xva to Citrix XenServer

For more details checkout xva README.

Xen config items

Basically you only need to adapt the 'disk' entry in order for xen to actually find your disk image. Another item that might need editng is 'vif' in environments where no bridged networking is used or the bridge has a different name than xenbr0. Here an overview of the option existing in the config file and what might have to be changed:

name

The name is what the appliance will appear as in the xen management tools like e.g. xm and has the keyword name
The guest will start without this item being changed

memory

This defines how much memory will be assigned to the guest. The keyword used is memory and the value given to it has the unit Megabyte.
The guest will start without this item being changed

disk

This defines on where the disk image containing the guest is located, what kind it is and how it will appear inside the guest as well as if access to it is read only or read/write. The keyword is disk
You need to edit this option in order to be able to start the guest.

As xen does not understand relative paths in its config file, you need to adapt the location in your configuration according to the location of the disk image. If you e.g unpacked the guest tar.gz file in /opt/guests so you now have the disk image located in /opt/guests/Appliance_name-Version/ you nedd to change the disk entry in the config from

  disk=[ "tap:aio:Appliance_name.architecture-versionraw,xvda,w" ]

to

  disk=[ "tap:aio:/opt/guests/Appliance_name-Version/Appliance_name.architecture-version.raw,xvda,w" ]

in order to be able to boot the guest.

network

The last item in the config determines on how the guest will access to hosts network using the keyword vif
There are several different options possible and explaining them would exceed the scope of this document. In general the default set value should work with correctly configured Xen Dom0s that use the default name for the bridge guests can connect to. The guest will start without this item being changed but it could happen that it misses network connectivity due to a different bridge name in the Dom0 or even a different method of making networking available to guests.

Please read How to configure networking for a Xen guest for more details on Xen bridged networking.

How to configure networking for a Xen guest

using xen tools

for having Xen guest access the network, the privileged Dom0 which has actual access to the network hardware in the machine needs to be prepared.

run /etc/xen/scripts/network-bridge

this will configure you a bridge 'xenbr0' and connect the ethernet interface of the machine to it

doing it manually

disable any specific configuration for your ethernet interface by removing its config file in /etc/sysconfig/network
create config file /etc/sysconfig/network/ifcfg-xenbr0 for the bridge xenbr0 with the following content:

BOOTPROTO='dhcp'
BRIDGE='yes'
BRIDGE_FORWARDDELAY='0'
BRIDGE_PORTS='eth0'
BRIDGE_STP='off'
BROADCAST=
ETHTOOL_OPTIONS=
IPADDR=
MTU=
NETMASK=
NETWORK=
REMOTE_IPADDR=
STARTMODE='onboot'
USERCONTROL='no'

restart your network b y running

/etc/init.d/network restart

Run `ip addr`. If everything works as expected, you should now see an interface xenbr0 which gets the host's IP address assigned and eth0 not having an IP address anymore. Ping some host to make sure everything works,

How to login to a Xen guest graphically

As a DomU Xen guest does not have access to a graphic card it not possible to start X directly inside it. As a result the startup scripts for X related items that run at bootup fail.
Working ways to use graphical applications are:

use ssh with X forwarding and start x application from ssh session

Requirements

The sshd has to be started inside the appliance
The ssh port needs to be opened in the firewall

X forwarding with ssh

in order to use X forwarding with ssh you need the option -X like this:

  ssh -X <username>@<hostname|ip adress of DomU>

once logged in you should be able to launch any X based application and get its graphical output forwarded to the machine your ssh client is running on.

configure xdm for remote access only

!!!WARNING!!! Using remote xdm to access your DomU's Desktop is a security risk as by default all traffic is unencrypted, even the username and password upon login. Use this method only in local networks you trust !!!WARNING!!!

On DomU

turn of firewall (the correct approach would be to open the right ports, but describing this here would exceed the scope of this document).
change in /etc/X11/xdm/xdm-config:

  DisplayManager.requestPort:    0

to

  !DisplayManager.requestPort:    0

change in /etc/sysconfig/displaymanager:

  DISPLAYMANAGER_STARTS_XSERVER="yes"

to

  DISPLAYMANAGER_STARTS_XSERVER="no"

run SuSEconfig
restart xdm

On Dom0 or another host

start X in an existing X session:

  Xnest :1 -query <Hostname/IP of DomU>

start X native

  X :1 -query <Hostname/IP of DomU>

This setup has been successful tested with xdm and kdm.

start a vncserver and access it from remote with a vncviewer

With latest images built in SUSE Studio this is already configured for xen guests, for older images you need to add the following line to the xenconfig file used to add/create a guest:

  vfb = ["type=vnc,vncunused=1,vnclisten=0.0.0.0"]

to access the guest you can either run (0 is the port used for the first guest being started, others then simply increase the port by one)

 vncviewer :0

or

 virt-viewer <guest name>|<guest ID>

This will then open a vnc view to the framebufer of the guest

make a second graphic card available to DomU via pci