If you did not migrate your account yet, visit https://idp-portal-info.suse.com/
openSUSE:SUSE Studio Xen Howtos
- 1 Note to Xen howtos
- 2 How to start a Xen guest
- 3 How to change Xen guest to Citrix xva
- 4 Xen config items
- 5 How to configure networking for a Xen guest
- 6 How to login to a Xen guest graphically
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.
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:
- 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
- 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
- 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" ]
disk=[ "tap:aio:/opt/guests/Appliance_name-Version/Appliance_name.architecture-version.raw,xvda,w" ]
- in order to be able to boot the guest.
- 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
- 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
- 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!!!
- 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:
- change in /etc/sysconfig/displaymanager:
- 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)
virt-viewer <guest name>|<guest ID>
This will then open a vnc view to the framebufer of the guest