Table of contents
- SUSE Studio Help
- Logging In
- Selecting a Base Template
- Viewing Your Home Page
- Importing Appliance Configurations from KIWI or AutoYast
- Selecting Software
- Updating via SUSE Lifecycle Management Server
- Selecting Appliance Formats
- Building Images
- Sending Feedback
- Viewing the Supportability Report
- SUSE Studio API
- More information
- How to contribute
- Legal Information
These howtos relate to Xen DomU appliances built with SUSE Studio. Some if not all of these changes can be made automatically by scripting them. 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 common practice to leave swap management to the hypervisor.
- How to start a Xen guest
- How to change Xen guest to Citrix xva
- Xen configuration options
- How to configure networking for a Xen guest
- How to log in to a Xen guest graphically
How to start a Xen guest
Every DomU Xen guest created in Studio comes as a .tar.gz package that needs to be unpacked to start the guest. The archive includes a directory containing two files:
Appliance_name-Version |---Appliance_name.architecture-version.raw |---Appliance_name.architecture-version.xenconfig
.raw file is the disk image and can be left untouched. The .xenconfig file contains the configuration for starting the guest and needs to be edited. Its 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 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 option 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 options in the config file and which might need changing follows 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, away from the xenconsole, which might appear like the boot process has stalled. 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, which requires confirmation but is not displayed on the xen console. You need to access the system with either a vncviewer or virt-viewer during first boot to accept the license. Once the license has been accepted, the boot process continues and finishes with a login prompt on the xenconsole. This workaround is only neccesarry for SLE products during first boot. See later sections for directions on how to access the guest using vnc.
In case you can only access the guest via the xen console during first boot, you need to add snippet “xencons=tty” to the grub kernel command. This will prevent a vnc login but will show all boot output including the license agreement dialogue in the xenconsole. During the next boot, you do not need repeat this. The login prompt will appear in the xenconsole after the system has been booted.
There is bug that the disk protocol “tap:aio” is not working reliably for SLES10 guests if they are started on a SLES10 host. You can work around the issue by replacing “tap:aio” by “file” in the SLES 10 guest .xenconfig file.
disk=[ "file:Appliance_name.architecture-version,xvda,w" ]
How to change Xen guest to Citrix xva
Xen appliances built with SUSE Studio can also be used with Citrix.
The following steps illustrate how to change Xen guest to Citrix xva.
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 SUSE Studio
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, refer to xva README.
Xen configuration options
Basically you only need to adapt the ‘disk’ entry for xen to find your disk image. Another line that might need editng is ‘vif’ in environments where no bridged networking is used or the bridge has a different name than xenbr0. Here is an overview of the keywords in the config file and which might need changing:
- Specifies with which name the appliance will appear in Xen management tools like xm.
- The guest will start without changes.
- Defines how much memory in Megabyte will be assigned to the guest.
- The guest will start without changes made here.
- Defines where the disk image containing the guest is located, what kind it is and how it will appear inside the guest, and if access is read only or read/write.
- You must edit this option 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 unpacked the guest tar.gz file in /opt/guests, the disk image is located in /opt/guests/Appliance_name-Version/. To be able to boot the guest, change the disk entry 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" ]
Determine how the guest will have access to the host’s network, using the keyword vif. There are several possible settings and explaining them all would exceed the scope of this document. In general, the default 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 not have network connectivity due to a different bridge name in the Dom0 or a different method of making networking available to guests.
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 a Xen guest to access the network, the privileged Dom0, which has actual access to the network hardware in the machine, needs to be prepared.
This will configure a bridge ‘xenbr0’ and connect it with the ethernet interface of the machine.
Disable any specific configuration for your ethernet interface by removing its config file in /etc/sysconfig/network.
Create config file
/etc/sysconfig/network/ifcfg-xenbr0for 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 by running
ip addr. If everything works as expected, you should see an interface xenbr0, with the host’s IP address assigned, while eth0 no longer has an IP address. Ping another host in the network to make sure everything works.
How to log in to a Xen guest graphically
- As a DomU Xen guest does not have access to a graphic card, it is not possible to start X directly on the guest. As a result, the startup scripts for X-related settings, which run at boot, fail.
- Working ways to use graphical applications are:
- use ssh with X forwarding and start x application from ssh session
- configure xdm for remote access only
- start a vncserver and access it from remote with a vncviewer
- make a second graphic card available to DomU via pci
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 open in the firewall.
X forwarding with ssh
To use X forwarding with ssh, you need the option -X:
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
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 during login. Use this method only in local networks you trust !!!WARNING!!!
Turn off the firewall (the correct approach would be to open the right ports, but describing this here would exceed the scope of this document).
/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”
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 successfully 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.
If virt-viewer is supposed to be run from a Studio built Dom0 with X forwarding, the packages virt-viewer and xorg-x11-fonts-scalable need to be added to the appliance before.