Citrix XenServer ® 5.6 Feature Pack 1 Virtual Machine Installation Guide

This is a guide to creating Virtual Machines (VMs) with XenServer™, the platform virtualization solution from Citrix®. It describes the various methods of getting VMs up and running on XenServer hosts for each of the supported guest operating systems.

This section summarizes the rest of the guide so that you can find the information you need. The following topics are covered:

XenServer documentation shipped with this release includes:

For additional resources, visit the Citrix Knowledge Center.

In addition to creating VMs from the provided templates, there are 3 other methods that you can use to create VMs.

2.2.2. Cloning an existing VM

You can make a copy of an existing VM by cloning from a template. Templates are ordinary VMs which are intended to be used as master copies to instantiate VMs from. A VM can be customized and converted into a template; be sure to follow the appropriate preparation procedure for the VM (see Section 7.7, “Preparing for Cloning a Windows VM using VSS” for Windows and Section 5.7, “Preparing to clone a Linux VM” for Linux).

	Note
	Templates cannot be used as normal VMs.

XenServer has two mechanisms for cloning VMs:

1. A full copy

2. Copy-on-Write (CoW)

   The faster Copy-on-Write (CoW) mode only writes modified blocks to disk and is only supported for file-backed VMs. CoW is designed to save disk space and allow fast clones, but will slightly slow down normal disk performance. A template can be fast-cloned multiple times without slowdown.

   	Note
   	If a template is cloned into a VM and the clone converted back into a template, disk performance can linearly decrease depending on the number of times this has happened. In this event, the vm-copy CLI command can be used to perform a full copy of the disks and restore expected levels of disk performance.

Notes for Resource Pools. If you create a template on a server where all VM virtual disks are on shared Storage Repositories (SR), the template cloning operation will be forwarded to any server in the pool that can access the shared SRs. However, if you create the template from a VM virtual disk that only has a local SR, then the template clone operation can only execute on the server that can access that SR.

2.2.3. Importing an Exported VM

You can create a VM by importing an existing exported VM. Like cloning, exporting and importing a VM is fast way to create additional VMs of a certain configuration so that you can increase the speed of your deployment. You might, for example, have a special-purpose server configuration that you use many times. Once you have set up a VM the way you want it, you can export it, and import it later to create another copy of your specially-configured VM. You can also use export and import to move a VM to a XenServer host that is in another resource pool.

When importing a VM, you can choose to preserve the MAC address on any virtual network interfaces associated with it. If you choose to generate a new MAC address, be sure to follow the appropriate preparation procedure for the imported VM. See Section 7.7, “Preparing for Cloning a Windows VM using VSS” for Windows and Section 5.7, “Preparing to clone a Linux VM” for Linux.

Importing an exported VM may take some time, depending on the size of the VM and the speed and bandwidth of the network connection between the XenServer host and XenCenter.

On VM import, XenServer re-attaches the VM virtual network interface (VIF) to the network that has the same name as the network on the server from which the VM was exported. If no matching network is found, the VM VIFs are attached to a new private network.

2.2.3.1. Exporting a VM

When you export a VM, a complete copy of the VM (including disk images) is stored as a single file on your local machine, with a .xva file extension. An existing VM can be exported using XenCenter or the XenServer Command Line Interface (CLI) . Additional instructions for using XenCenter, are available in the XenCenter online Help.

The following procedure assumes that you have multiple XenServer hosts and that you are administering them using the CLI on a separate machine (that is, a machine that is not one of the XenServer hosts) where you can maintain a library of export files. Citrix recommends not exporting a VM to a XenServer host filesystem.

To Export a VM using XenCenter

1. In the Resources pane, select the VM, then right click and select Shut Down.

2. Right click on the VM, and select Export to File.

3. Enter a name for the export file and specify the folder where you want it to be saved.

4. Click Save to begin exporting the file.

   The export progress is displayed in the status bar at the bottom of the XenCenter window and also on the Logs tab.

5. The saved file has a *.xva extension.

	Note
	Exporting a VM may take some time, depending on its size and the speed and bandwidth of the network connection.

To Export a VM Using the CLI

1. Shut down the VM that you want to export.

2. Run the following commands to export the VM:

   xe vm-export -h <hostname> -u <root> -pw <password> vm=<vm_name> \
   filename=<pathname_of_file>

   	Note
   	Be sure to include the .xva extension when specifying the export filename. If the exported VM does not have this extension and you attempt to import it using XenCenter, it might fail to recognize the file as a valid XVA file.

2.2.3.2. Importing a VM

An exported VM file can be imported using XenCenter or the CLI.

To Import a VM using XenCenter

1. In the Resources pane, select a host or a Pool, then right-click and select Import.

2. Follow the Import wizard.

3. Importing a VM, template or snapshot involves the same steps as creating and provisioning a new VM using the New VM wizard, that is, nominating a home server, and configuring storage and networking for the new VM.

	Note
	The import progress is displayed in the status bar at the bottom of the XenCenter window and also on the Logs tab. The import process may take some time, depending on the size of the VM and the speed and bandwidth of the network connection between XenCenter and the destination server. When the newly-imported VM is available, it appears in the Resources pane.

	Warning
	It may not always be possible to run an imported VM that was exported from another server with a different CPU type. For example, a Windows VM created on a server with an Intel VT Enabled CPU, then exported, may not run when imported to a server with an AMD-VTM CPU.

To Import a VM Using the CLI

1. To import the VM to the default SR on the target XenServer host:

   xe vm-import -h <hostname> -u <root> -pw <password> \
   filename=<pathname_of_export_file>

   You can import the VM to another SR on the target XenServer host by adding the optional sr-uuid parameter:

   xe vm-import -h <hostname> -u <root> -pw <password> \
   filename=<pathname_of_export_file> sr-uuid=<uuid_of_target_sr>

   You can also preserve the MAC address of the original VM by adding the optional preserve parameter set to true:

   xe vm-import -h <hostname> -u <root> -pw <password> \
   filename=<pathname_of_export_file> preserve=true

2. Import process may take some time, depending on the size of the VM and the speed and bandwidth of the network connection. When finished, the command prompt returns the UUID of the newly-imported VM.

XenServer Tools must be installed for each Virtual Machine (Windows and Linux) in order for the VM to have a fully supported configuration, and to be able to use the XenServer management tools (the xe CLI or XenCenter). A Windows VM will function without them, but performance will be significantly hampered unless the tools are installed.

Without the tools being installed, you cannot:

For further information about XenServer Tools see Section 7.2, “XenServer Tools”

	Warning
	Running a VM without installing the XenServer Tools is not a supported configuration.

When installing VMs, follow the memory and disk space guidelines of the operating system and any relevant applications, when allocating resources such as memory and disk space.

	Note
	Individual versions of the operating systems may also impose their own maximum limits on the amount of memory supported (for example, for licensing reasons).

	Warning
	When configuring guest memory, do not to exceed the maximum amount of physical memory addressable by your operating system. Setting a memory maximum that is greater than the operating system supported limit may lead to stability problems within your guest.

Note

Some 32-bit Windows operating systems can support more than 4 GB of RAM through the use of a special mode: physical address extension (PAE) mode. If you want to reconfigure a VM with greater than 4 GB of RAM, you must use the xe CLI, not XenCenter, as the CLI does not impose any upper bounds for memory-static-max. For more information on how to set the memory static max, please refer to the Dynamic Memory Control chapter, in the XenServer Administrator's Guide.

The current version of the XenServer product family has the following general limitations on virtual devices for VMs. Note that specific guest operating systems may have lower limits for certain features. The individual guest installation section notes the limitations.

The process of installing a Windows on to a VM can be broken down into three steps:

Windows operating systems are installed onto VMs by cloning an appropriate template using either XenCenter or the xe CLI, and then installing the operating system. The templates for individual guests have predefined platform flags set which define the configuration of the virtual hardware. For example, all Windows VMs are installed with the ACPI Hardware Abstraction Layer (HAL) mode enabled. If you subsequently change one of these VMs to have multiple virtual CPUs, Windows automatically switches the HAL to multi-processor mode.

The available Windows templates are listed below:

The Demo Linux VM template provided with XenServer can be used to create a VM running Linux without the need for vendor installation media. This can be useful for testing purposes. For example, Demo Linux VMs allow quick and simple VM creation for use with XenServer product features such as XenMotion, Dynamic Memory Control, and High Availability.

	Warning
	Demo Linux VMs should not be used for running production workloads.

The VMs are instantiated by running the vm-install command on the CLI, or by cloning the template using XenCenter. For example, using the CLI on Linux:

xe vm-install template="Demo Linux VM"  new-name-label=<demo>

When you first boot the VM you are prompted for a root password, a VNC password (for graphical use), and a hostname. You will need to add a network interface if you installed the VM using the CLI.

	Note
	The Demo Linux VM template is only available if you install the separate Linux pack (that is, the linux.iso).

Debian Lenny is installed using the standard Debian installer, which supports installation into a PV VM (performance optimized). Use XenCenter or the xe CLI to install Debian Lenny either from a CD, ISO library, or from a network repository over FTP or HTTP.

Before installing Debian Lenny from a network repository, follow the Debian instructions for preparing for network installations, including how to set up a mirror. Full installations from network repositories are not completely supported. While you can load the kernel and RAM disk from repository, the Debian installation program requires that you specify an HTTP or FTP URL.

Information on installing Debian Lenny using XenCenter is available in the XenCenter help — to get started, run the New VM wizard. The rest of this section provides information about installing Debian Lenny using the CLI.

	Note
	If you want to perform a Debian Lenny installation from the DVD, then you must obtain a suitable Debian Lenny DVD image that is compatible with XenServer. The standard images Debian provides are not compatible with XenServer. For details on how to obtain this DVD image, see the Debian Lenny article on the Citrix Developer Network (http://community.citrix.com/display/xs/Debian+Lenny).

This section provides an overview of installing Red Hat, CentOS, Oracle Enterprise, and SUSE Enterprise.

For information about the general Linux VM installation process, see Chapter 5, Installing Linux Operating Systems onto VMs.

Installing RHEL 5.x/CentOS/OEL 5.x

When you want to create a RHEL 5.x/CentOS/OEL 5.x VM, you must ensure the operating system will use the RHEL 5.4 kernel (2.6.18-164.el5) or higher, which is available from the distribution vendor.

Note

Enterprise Linux (EL) kernel versions prior to 5.4 contain issues that prevent proper operation as a XenServer VM. In previous XenServer releases, Citrix provided a 5.x kernel with fixes for those issues and required its installation. Since the required fixes are now available in 5.4 (2.6.18-164.el5) and later kernels, Citrix no longer supplies a 5.x kernel. Instead, Citrix requires use of a 5.4 or later kernel.

Installing RHEL 4.5 to 4.8

When you want to create a RHEL 4.5 to 4.8 VM, you must install the Citrix-provided RHEL 4.8 kernel after installing the operating system. Citrix includes this kernel in the XenServer Tools for VMs, and it fixes issues in the RHEL kernel which prevents XenServer from running correctly.

Installing RHEL 4.5 to 4.8 requires using the following process:

5.3.1. Installing Red Hat, CentOS, Oracle Enterprise, and SUSE Enterprise Linux from vendor media

XenServer supports the installation of the following Linux operating systems from vendor media in the XenServer host DVD/CD-ROM drive:

• Red Hat Enterprise Linux 5.0-5.4, 32-bit

• Red Hat Enterprise Linux 5.0-5.4, 64-bit

• CentOS 4.5-4.6

• CentOS 5.0-5.4, 32-bit

• CentOS 5.0-5.4, 64-bit

• Oracle Enterprise Linux 5.0-5.4, 32-bit

• Oracle Enterprise Linux 5.0-5.4, 64-bit

• SUSE Enterprise Linux, 10, SP1, SP2, 32-bit

• SUSE Enterprise Linux, 10, SP1, SP2, SP3, 64-bit

• SUSE Enterprise Linux, 11, 32-bit

• SUSE Enterprise Linux, 11, 64-bit

Other Linux operating systems need to be installed from a network installation server. See Section 5.3.2, “Installing Linux from a network installation server to a VM”.

To install a supported Linux VM from vendor media using the CLI

1. Insert the vendor installation CD into the CD drive on the XenServer host.

2. Run the command xe template-list to find the name of the template corresponding to the OS you want to install.

3. Run the command:

   xe vm-install template="<template_name>" new-name-label=<name_for_vm>

   This command returns the UUID of the new VM.

4. Get the UUID of the root disk of the new VM:

   xe vbd-list vm-uuid=<vm_uuid> userdevice=0 params=uuid --minimal

5. Using the UUID returned, set the root disk to not be bootable:

   xe vbd-param-set uuid=<root_disk_uuid> bootable=false

6. Get the name of the physical CD drive on the XenServer host:

   xe cd-list

   The result of this command should give you something like SCSI 0:0:0:0 for the name-label field.

7. Add a virtual CD-ROM to the new VM using the XenServer host CD drive name-label parameter as the cd-name parameter:

   xe vm-cd-add vm=<vm_name> cd-name="<host_cd_drive_name_label>" device=3

8. Get the UUID of the VBD corresponding to the new virtual CD drive:

   xe vbd-list vm-uuid=<vm_uuid> type=CD params=uuid --minimal

9. Make the VBD of the virtual CD bootable:

   xe vbd-param-set uuid=<cd_drive_uuid> bootable=true

10. Set the install repository of the VM to be the CD drive:

    xe vm-param-set uuid=<vm_uuid> other-config:install-repository=cdrom

11. Start the VM

    xe vm-start uuid=<vm_uuid>

12. Open a console to the VM with XenCenter or an SSH terminal and follow the steps to perform the OS installation.

Note

The console in XenCenter supports VNC graphical installation of the Red Hat, Oracle, and CentOS operating systems. Ensure that the virtual machine has enough memory allocated for this to be enabled. If you set the memory allocation to 512MB or higher, you will be prompted to start VNC after the initial text screens. Choosing to continue using VNC and setting a password will enable the Switch to Graphical Console button.

5.3.2. Installing Linux from a network installation server to a VM

The XenServer guest installer allows you to install an operating system from a network-accessible copy of vendor media onto a VM. To prepare for installing from vendor media, make an exploded network repository of your vendor media (not ISO images) and export it over NFS, HTTP or FTP so that it is accessible to the XenServer host administration interface. See Appendix D, Setting Up a Red Hat Installation Server for information on how to copy a set of installation CDs to a network drive.

The network repository must be accessible from the control domain of the XenServer host, normally using the management interface. The URL must point to the base of the CD/DVD image on the network server, and be of the form:

• HTTP. http://<server>/<path>

• FTP. ftp://<server>/<path>

• NFS SUSE-based distributions. nfs://<server>/<path>

• NFS RED HAT-based distributions. nfs:<server>:/<path>

See the vendor installation instructions for information about how to prepare for a network-based installation, such as where to unpack the ISO.

Note that when using the NFS installation method from XenCenter, the nfs:// style of path should always be used. XenCenter will then modify this into the correct form when passing it to the server automatically. When using the CLI as per the instructions below, the appropriate form must be chosen manually. In the case of SUSE-based distributions this is the nfs://<server>/<path> style, and in the case of Red-Hat based distributions this is nfs:<server>:/<path>.

When creating VMs from templates, the XenCenter New VM wizard prompts you for the repository URL. When using the CLI, install the template as normal using vm-install and then set the other-config:install-repository parameter to the value of the URL. When the VM is subsequently started, it will begin the network installation process.

	Note
	When installing a new Linux-based VM, it is important to fully finish the installation and reboot it before performing any other operations on it. This is analogous to not interrupting a Windows installation — which would leave you with a non-functional VM.

To install a Linux VM from a network-accessible copy of vendor media using the CLI

1. Run the command

   xe vm-install template=<template> new-name-label=<name_for_vm> \
   sr-uuid=<storage_repository_uuid>

   This command returns the UUID of the new VM.

2. Find the UUID of the network that you want to connect to. For example, if it is the one attached to xenbr0:

   xe network-list bridge=xenbr0 --minimal

3. Create a VIF to connect the new VM to this network:

   xe vif-create vm-uuid=<vm_uuid> network-uuid=<network_uuid> mac=random device=0

4. Set the install-repository key of the other-config parameter to the path of your network repository. For example, to use http://server/RedHat/5.0 as the URL of the vendor media:

   xe vm-param-set uuid=<vm_uuid> \
   other-config:install-repository=<http://server/redhat/5.0>

5. Start the VM

   xe vm-start uuid=<vm_uuid>

6. Connect to the VM console using XenCenter or VNC and perform the OS installation.

5.3.3. Installing RHEL using a kickstart file

When you are installing RHEL through New VM wizard in XenCenter, you can automate the installation by using a Red Hat Kickstart file. A Red Hat Kickstart file is an automated installation method, similar to an answer file, you can use to provide responses to the RHEL installation prompts. To create this file, install RHEL manually. The kickstart file is located in /root/anaconda-ks.cfg.

To install RHEL Linux using a custom kickstart file (from XenCenter)

1. In XenCenter, choose the appropriate RHEL template

2. Specify the kickstart file to use as a kernel command-line argument in the XenCenter New VM Wizard, exactly as it would be specified in the PXE config file, for example:

   ks=http://server/fileksdevice=eth0

3. On the command line, use vm-param-set to set the PV-args parameter to make use of a Kickstart file

   xe vm-param-set uuid=<vm_uuid> PV-args=<"ks=http://server/path ksdevice=eth0">

4. Set the repository location so XenServer knows where to get the kernel and initrd from for the installer boot:

   xe vm-param-set uuid=<vm_uuid> other-config:install-repository=<http://server/path>

	Note
	To install using a kickstart file without the New VM wizard, you can add the appropriate command to the Advanced OS boot parameters text box. For example, for RHEL 5.4, this command would be ks=nfs:telos:/linux/distros/auto-install/rhel54.cfg.

Although all the supported Linux distributions are natively paravirtualized (and therefore do not need special drivers for full performance), XenServer includes a guest agent which provides additional information about the VM to the host. This additional information includes:

It is important to install this agent and keep it up-to-date (see Chapter 6, Updating VMs) as you upgrade your XenServer host.

Note

CD-ROM drives and ISOs attached to Linux Virtual Machines appear as /dev/xvdd instead of as /dev/cdrom as you might expect. This is because they are not true CD-ROM devices, but normal devices. When the CD is ejected by either XenCenter or the CLI, it hot-unplugs the device from the VM and the device disappears. This is different from Windows Virtual Machines, where the CD remains in the VM in an empty state.

By default, the clocks in a Linux VM are synchronized to the clock running on the control domain, and cannot be independently changed. This mode is a convenient default, since only the control domain needs to be running the NTP service to keep accurate time across all VMs. Upon installation of a new Linux VM, make sure you change the time-zone from the default UTC to your local value (see Section B.1, “Release Notes” for specific distribution instructions).

VMs might not be set up to support Virtual Network Computing (VNC), which XenServer uses to control VMs remotely, by default. Before you can connect with the XenCenter graphical console, you need to ensure that the VNC server and an X display manager are installed on the VM and properly configured. This section describes the procedures for configuring VNC on each of the supported Linux operating system distributions to allow proper interactions with the XenCenter graphical console.

CentOS-based VMs should use the instructions for the Red Hat-based VMs below, as they use the same base code to provide graphical VNC access. CentOS 4 is based on Red Hat Enterprise Linux 4, and CentOS 5 is based on Red Hat Enterprise Linux 5.

5.6.1. Enabling a graphical console on Red Hat, CentOS, or Oracle Linux VMs

	Note
	Before setting up your Red Hat VMs for VNC, be sure that you have installed the Linux guest agent. See Section 5.4, “Installing the Linux guest agent” for details.

To configure VNC on Red Hat VMs, you need to modify the GDM configuration. The GDM configuration is held in a file whose location varies depending on the version of Red Hat Linux you are using. Before modifying it, first determine the location of this configuration file; this file will then be modified in a number of subsequent procedures in this section.

5.6.1.1. Determining the location of your VNC configuration file

If you are using Red Hat Linux version 4 the GDM configuration file is /etc/X11/gdm/gdm.conf. This is a unified configuration file that contains default values as specified by the provider of your version of GDM in addition to your own customized configuration. This type of file is used by default in older versions of GDM, as included in these versions of Red Hat Linux.

If you are using Red Hat Linux version 5 the GDM configuration file is /etc/gdm/custom.conf. This is a split configuration file that contains only user-specified values that override the default configuration. This type of file is used by default in newer versions of GDM, as included in these versions of Red Hat Linux.

5.6.1.2. Configuring GDM to use VNC

1. As root on the text CLI in the VM, run the command rpm -q vnc-server gdm. The package names vnc-server and gdm should appear, with their version numbers specified.

   If these package names are displayed, the appropriate packages are already installed. If you see a message saying that one of the packages is not installed, then you may not have selected the graphical desktop options during installation. You will need to install these packages before you can continue. See the appropriate Red Hat Linux x86 Installation Guide for details regarding installing additional software on your VM.

2. Open the GDM configuration file with your preferred text editor and add the following lines to the file:

   [server-VNC]
   name=VNC Server
   command=/usr/bin/Xvnc -SecurityTypes None -geometry 1024x768 -depth 16 \
   -BlacklistTimeout 0
   flexible=true

   • With configuration files on Red Hat Linux 3 and 4, this should be added above the [server-Standard] section.

   • With configuration files on Red Hat Linux 5, this should be added into the empty [servers] section.

3. Modify the configuration so that the Xvnc server is used instead of the standard X server:

   • If you are using Red Hat Linux 3 or 4, there will be a line just above that reads:

     0=Standard

     Modify it to read:

     0=VNC

   • If you are using Red Hat Linux 5 or greater, add the above line just below the [servers] section and before the [server-VNC] section.

4. Save and close the file.

Restart GDM for your change in configuration to take effect, by running the command /usr/sbin/gdm-restart.

	Note
	Red Hat Linux uses runlevel 5 for graphical startup. If your installation is configured to start up in runlevel 3, change this for the display manager to be started (and therefore to get access to a graphical console). See Section 5.6.3, “Checking runlevels” for further details.

5.6.1.3. Firewall settings

The firewall configuration by default does not allow VNC traffic to go through. If you have a firewall between the VM and XenCenter, you need to allow traffic over the port that the VNC connection uses. By default, a VNC server listens for connections from a VNC viewer on TCP port 5900 + n, where n is the display number (usually just zero). So a VNC server setup for Display-0 will listen on TCP port 5900, Display-1 is TCP-5901, and so on. Consult your firewall documentation to make sure these ports are open.

You might want to further customize your firewall configuration if you want to use IP connection tracking or limit the initiation of connections to be from one side only.

To customize Red Hat-based VMs firewall to open the VNC port

1. For Red Hat Linux 4 and 5, use system-config-securitylevel-tui.

2. Select “Customize” and add 5900 to the other ports list.

Alternatively, you can disable the firewall until the next reboot by running the command service iptables stop, or permanently by running chkconfig iptables off. This can of course expose additional services to the outside world and reduce the overall security of your VM.

5.6.1.4. VNC screen resolution

If, after connecting to a VM with the graphical console, the screen resolution is mismatched (for example, the VM display is too big to comfortably fit in the Graphical Console pane), you can control it by setting the VNC server geometry parameter as follows:

1. Open the GDM configuration file with your preferred text editor. See Section 5.6.1.1, “Determining the location of your VNC configuration file” for information about determining the location of this file.

2. Find the [server-VNC] section you added above.

3. Edit the command line to read, for example:

   command=/usr/bin/Xvnc -SecurityTypes None -geometry 800x600

   where the value of the geometry parameter can be any valid screen width and height.

4. Save and close the file.

5.6.2. Setting up SLES-based VMs for VNC

	Note
	Before setting up your SUSE Linux Enterprise Server VMs for VNC, be sure that you have installed the Linux guest agent. See Section 5.4, “Installing the Linux guest agent” for details.

SLES has support for enabling “Remote Administration” as a configuration option in YaST. You can select to enable Remote Administration at install time, available on the Network Services screen of the SLES installer. This allows you to connect an external VNC viewer to your guest to allow you to view the graphical console; the methodology for using the SLES remote administration feature is slightly different than that provided by XenCenter, but it is possible to modify the configuration files in your SUSE Linux VM such that it is integrated with the graphical console feature.

5.6.2.1. Checking for a VNC server

Before making configuration changes, verify that you have a VNC server installed. SUSE ships the tightvnc server by default; this is a suitable VNC server, but you can also use the standard RealVNC distribution if you prefer.

You can check that you have the tightvnc software installed by running the command:

rpm -q tightvnc

5.6.2.2. Enabling Remote Administration

If Remote Administration was not enabled during installation of the SLES software, you can enable it as follows:

1. Open a text console on the VM and run the YaST utility:

   yast

2. Use the arrow keys to select Network Services in the left menu, then Tab to the right menu and use the arrow keys to select Remote Administration. Press Enter.

3. In the Remote Administration screen, Tab to the Remote Administration Settings section. Use the arrow keys to select Allow Remote Administration and press Enter to place an X in the check box.

4. Tab to the Firewall Settings section. Use the arrow keys to select Open Port in Firewall and press Enter to place an X in the check box.

5. Tab to the Finish button and press Enter.

6. A message box is displayed, telling you that you will need to restart the display manager for your settings to take effect. Press Enter to acknowledge the message.

7. The original top-level menu of YaST appears. Tab to the Quit button and press Enter.

5.6.2.3. Modifying the xinetd configuration

After enabling Remote Administration, you need to modify a configuration file if you want to allow XenCenter to connect, or else use a third party VNC client.

1. Open the file /etc/xinetd.d/vnc in your preferred text editor.

   The file contains sections like the following:

   service vnc1
   {
   socket_type = stream
   protocol    = tcp
   wait        = no
   user        = nobody
   server      = /usr/X11R6/bin/Xvnc
   server_args = :42 -inetd -once -query localhost -geometry 1024x768 -depth 16
   type        = UNLISTED
   port        = 5901
   }

2. Edit the port line to read

   port = 5900

3. Save and close the file.

4. Restart the display manager and xinetd service with the following commands:

   /etc/init.d/xinetd restart
   rcxdm restart

SUSE Linux uses runlevel 5 for graphical startup. If your remote desktop does not appear, verify that your VM is configured to start up in runlevel 5. Refer to Section 5.6.3, “Checking runlevels” for details.

5.6.2.4. Firewall settings

By default the firewall configuration does not allow VNC traffic to go through. If you have a firewall between the VM and XenCenter, you need to allow traffic over the port that the VNC connection uses. By default, a VNC server listens for connections from a VNC viewer on TCP port 5900 + n, where n is the display number (usually just zero). So a VNC server setup for Display-0 will listen on TCP port 5900, Display-1 is TCP-5901, etc. Consult your firewall documentation to make sure these ports are open.

You might want to further customize your firewall configuration if you want to use IP connection tracking or limit the initiation of connections to be from one side only.

To open the VNC port on a SLES-based VMs firewall

1. Open a text console on the VM and run the YaST utility:

   yast

2. Use the arrow keys to select Security and Users in the left menu, then Tab to the right menu and use the arrow keys to select Firewall. Press Enter.

3. In the Firewall screen, Tab to the Firewall Configuration: Settings section. Use the arrow keys to select the Allowed Services in the left menu.

4. Tab to the Firewall Configuration: Allowed Services fields on the right. Use the arrow keys to select the Advanced... button (near the bottom right, just above the Next button) and press Enter.

5. In the Additional Allowed Ports screen, enter 5900 in the TCP Ports field. Tab to the OK button and press Enter.

6. Tab back to the list of screens on the left side and use the arrow keys to select Start-Up. Tab back to the right and Tab to the Save Settings and Restart Firewall Now button and press Enter.

7. Tab to the Next button and press Enter, then in the Summary screen Tab to the Accept button and press Enter, and finally on the top-level YaST screen Tab to the Quit button and press Enter.

8. Restart the display manager and xinetd service with the following commands:

   /etc/init.d/xinetd restart
   rcxdm restart

Alternatively, you can disable the firewall until the next reboot by running the rcSuSEfirewall2 stop command, or permanently by using YaST. This can of course expose additional services to the outside world and reduce the overall security of your VM.

5.6.2.5. VNC screen resolution

If, after connecting to a Virtual Machine with the Graphical Console, the screen resolution is mismatched (for example, the VM display is too big to comfortably fit in the Graphical Console pane), you can control it by setting the VNC server geometry parameter as follows:

1. Open the /etc/xinetd.d/vnc file with your preferred text editor and find the service_vnc1 section (corresponding to displayID 1).

2. Edit the geometry argument in the server-args line to the desired display resolution. For example,

   server_args  = :42 -inetd -once -query localhost -geometry 800x600 -depth 16

   where the value of the geometry parameter can be any valid screen width and height.

3. Save and close the file.

4. Restart the VNC server:

   /etc/init.d/xinetd restart
   rcxdm restart

Typically, when cloning a VM or a computer, unless you "generalize" the cloned image, attributes unique to that machine, such as the IP address, SID, or MAC address, will be duplicated in your environments.

As a result, XenServer automatically changes some virtual hardware parameters when you clone a Linux VM. If you copy the VM using XenCenter, XenCenter automatically changes the MAC address and IP address for you. If these interfaces are configured dynamically in your environment, you might not need to make any modifications to the cloned VM. However, if the interfaces are statically configured, you might need to modify their network configurations.

The VM may need to be customized to be made aware of these changes. For instructions for specific supported Linux distributions, see Section B.1, “Release Notes”.

	Warning
	Before updating Windows operating systems you must uninstall the XenServer Tools. If they are present during the attempt to update, the update will fail.

Windows installation disks typically provide an upgrade option if you boot them on a server which has an earlier version of Windows already installed.

You can update the operating system of Windows VMs in a similar way.

Once the operating system update is complete, reinstall the XenServer Tools just as you would after installing a fresh Windows VM. See Section 7.2, “XenServer Tools” for details.

The XenServer Tools are available in XenCenter on the built-in xs-tools.iso. On the VM menu, select Install XenServer Tools; this attaches the CD image containing the XenServer Tools to the VM. If Autoplay is enabled for the VM CD drive, installation will be started automatically after a few moments. If Autoplay is not enabled, double-click on the CD drive, and select xensetup.exe to begin the XenServer Tools installation. Follow the on-screen prompts to install the new drivers, which will automatically deactivate and upgrade the old drivers.

The Linux guest utilities can be updated by rerunning the Linux/install.sh script from the built-in xs-tools.iso CD image (see Section 5.4, “Installing the Linux guest agent”). From time to time, Citrix also supplies updated RHEL 4.x Linux kernels for supported distributions on its Web site (http://updates.vmd.citrix.com/XenServer/5.6.0/rhel4x/). Because Citrix no longer provides RHEL 5.x kernels, you should obtain updates to RHEL 5.4 and higher kernels directly from Red Hat.

Rerunning the Linux/install.sh script from the built-in xs-tools.iso is particularly important for CentOS versions prior to 5.3, where you will get the upstream kernel by default, which has certain limitations (see Section B.1, “Release Notes”).

For yum-enabled distributions (CentOS 4 and 5, RHEL 5.4 and higher), xe-guest-utilities installs a yum configuration file to enable subsequent updates to be done using yum in the standard manner.

For Debian, /etc/apt/sources.list is populated to enable updates using apt by default.

When upgrading, Citrix recommends that you always rerun Linux/install.sh when you upgrade. This script automatically determines if your VM needs a kernel update and installs it if necessary.

	Note
	SLES is also supported, but Citrix does not provide an updated kernel.

To make an ISO library available to XenServer hosts, create an external NFS or SMB/CIFS share directory. The NFS or SMB/CIFS server must allow root access to the share. For NFS shares, this is accomplished by setting the no_root_squash flag when you create the share entry in /etc/exports on the NFS server.

Then either use XenCenter to attach the ISO library, or connect to the host console and run the command:

xe-mount-iso-sr host:/volume

For advanced use, additional arguments to the mount command may be passed.

If making a Windows SMB/CIFS share available to the XenServer host, either use XenCenter to make it available, or connect to the host console and run the following command:

xe-mount-iso-sr unc_path -t smbfs -o username=myname/myworkgroup

The unc_path argument should have back-slashes replaced by forward-slashes. -t cifs can be used for CIFS instead of SMB. For example:

xe-mount-iso-sr //server1/myisos -t cifs -o username=johndoe/mydomain
xe-mount-iso-sr //server2/iso_share -t smbfs -o username=alice

After mounting the share, any available ISOs will be available from the Install from ISO Library or DVD drive drop-down list in XenCenter, or as CD images from the CLI commands.

The ISO should be attached to an appropriate Windows template.

The Citrix paravirtualized network and SCSI drivers (XenServer Tools) provide high performance I/O services without the overhead of traditional device emulation. These drivers replace the emulated devices and provide high-speed transport between Windows and the XenServer product family software. During the installation of a Windows operating system, XenServer uses traditional device emulation to present a standard IDE controller and a standard network card to the VM. This allows Windows to complete its installation using built-in drivers, but with reduced performance due to the overhead inherent in emulation of the controller drivers.

If you are working with a VM that does not have XenServer Tools installed, a Tools not installed message in red text will be visible on the General tab in the properties pane. A message will also be displayed here if XenServer has been updated and the VM has an older version of XenServer Tools from an earlier release. In this case, the message displayed is Tools out of date (version x.y installed). For a Windows VM, you can double-click on this text to switch to the VM console, load the Tools ISO, and launch the Tools installation wizard; for Linux VMs, you can double-click on this text to switch to the VM console and load the Tools ISO (however, you must mount the ISO and manually run the installation.

After Windows is installed, install the XenServer Tools. These are on an ISO available to the virtual CD-ROM drive of the Virtual Machine.

	Note
	While a Windows VM functions without them, performance is significantly hampered unless these drivers are installed. Running Windows VMs without these drivers is not supported. Some features, such as live relocation across physical hosts, will only work with the PV drivers installed and active.

Attach the Windows PV drivers ISO to the VM by using the Install Tools menu in XenCenter, or by directly attaching the built-in xs-tools.iso ISO image on the VM using the CLI. Once the ISO is attached, double-click on the xensetup.exe installer executable and follow the on-screen prompts.

	Note
	To silently install the XenServer Tools and prevent the system from rebooting afterwards, use the /S and /norestart options: <install_dir>/xensetup.exe /S /norestart

The Windows PV drivers are installed by default in the C:\Program Files\Citrix\XenTools directory on the VM.

The XenServer Tools can also be installed on a provisioned Windows machine by running the executable windows-pvdrivers-xensetup.exe, located in the client_install/ directory of the installation CD.

The Windows tools also include a XenServer VSS provider that is used to quiesce the guest filesystem in preparation for a VM snapshot. The VSS provider is installed as part of the PV driver installation, but is not enabled by default.

	Note
	The VSS provider is automatically uninstalled when the PV drivers are uninstalled, and need to be activated again upon re-installation. They can be uninstalled separately from the PV drivers by using uninstall-XenProvider.cmd in the same directory.

There are two ways of viewing a Windows VM console, both of which support full keyboard and mouse interactivity.

In XenCenter on the Console tab, there is a Switch to Remote Desktop button. This button disables the standard graphical console within XenCenter, and switches to using Remote Desktop.

If you do not have Remote Desktop enabled in the VM, this button will be disabled. To enable it, you will need to install the XenServer Tools (PV drivers) and follow the procedure below to enable it in each VM that you want to connect using Remote Desktop:

You will now be able to connect to this VM using Remote Desktop. For more information, see the Microsoft Knowledge Base article, Connect to another computer using Remote Desktop Connection

	Note
	You cannot connect to a VM that is asleep or hibernating, so make sure the settings for sleep and hibernation on the remote computer are set to Never.

For Windows guests, time is initially driven from the control domain clock, and is updated during VM lifecycle operations such as suspend, reboot and so on. Citrix highly recommends running a reliable NTP service in the control domain and all Windows VMs.

So if you manually set a VM to be 2 hours ahead of the control domain (for example, using a time-zone offset within the VM), then it will persist. If you subsequently change the control domain time (either manually or if it is automatically corrected by NTP), the VM will shift accordingly but maintain the 2 hour offset. Note that changing the control domain time-zone does not affect VM time-zones or offset. It is only the hardware clock setting which is used by XenServer to synchronize the guests.

When performing suspend/resume operations or live relocation using XenMotion, it is important to have up-to-date XenServer Tools installed, as they notify the Windows kernel that a time synchronization is required after resuming (potentially on a different physical host).

A XenServer VM can be:

To allow installation of Reseller Option Kit (BIOS-locked) OEM versions of Windows, onto a VM running on a XenServer host, the BIOS strings of the VM will need to be copied from the host with which the ROK media was supplied.

In order to install the BIOS-locked media that came with your host, you will need to follow the steps below:

	Note
	When you start the VM, it will be started on the physical host from which you copied the BIOS strings.

	Warning
	It is your responsibility to comply with any EULAs governing the use of any BIOS-locked operating systems that you install.

The only supported way to clone a windows VM is by using the Windows utility sysprep to prepare the VM.

Computers running Windows operating systems are uniquely identified by a Security ID (SID). When cloning a Windows VM, it is important to take steps to ensure the uniqueness of the SID. Cloning an installation without taking the recommended system preparation steps can lead to duplicate SIDs and other problems. Because the SID identifies the computer or domain as well as the user, it is critical that it is unique. Refer to the Microsoft KnowledgeBase article 314828, "The Microsoft policy for disk duplication of Windows installations," for more information.

sysprep modifies the local computer SID to make it unique to each computer. The sysprep binaries are on the Windows product CDs in the \support\tools\deploy.cab file.

The steps that you need to take to clone Windows VMs are:

	Note
	The original, sysprepped VM (the "source" VM) should not be restarted again after the sysprep stage, and should be converted to a template immediately afterwards to prevent this. If the source VM is restarted, sysprep must be run on it again before it can be safely used to make additional clones.

For more information on using sysprep, visit the following Microsoft websites:

Windows 7 - The Windows Automated Installation Kit (AIK) for Windows 7

Windows XP - How to use the Sysprep tool to automate successful deployment of Windows XP

Windows Server 2003 - What Is Sysprep?

The XenServer OVF Appliance Wizard comprises three wizards: Appliance Export, Appliance Import, and Disk Image Import.

This illustration shows how selecting a host and right-clicking on it is the only way to launch the Disk Image Import wizard.

To start an Appliance Wizard, select the object in the XenCenter tree where you want to export from or import to, and then select one of the following:

	Tip
	You can also start the Appliance Export and Appliance Import wizards by right-clicking on an object and selecting the menu command.

When you launch an Appliance Wizard, the node you selected in the XenCenter tree determines the scope of the wizard. For example, if you select a host and then launch the Appliance Export Wizard, the wizard only displays the VMs that are powered off on that host.

This illustration shows how when a user selects Host84 before launching the Appliance Export Wizard, the wizard automatically narrows its scope to only the powered off VMs on that host.

The Appliance Import Wizard supports importing OVF appliance packages. However, due to subtle incompatibilities, the Appliance Import Wizard cannot import all OVF content. See Section 8.2, “XenServer OVF Appliance Wizard requirements” for a list of tested OVF content.

The XenServer OVF Appliance Wizard also gives you the ability to export packages in OVF and OVA format. For example, you could export a complete XenApp farm that you have already prepared for deployment with Sysprep, the System Preparation Utility by Microsoft for Windows deployments.

The XenServer OVF Appliance Wizard supports importing OVF content produced from the following utilities:

The XenServer OVF Appliance Wizard requires the following:

Both OVF and OVA formats are appliance-package standards defined by the Distributed Management Task Force (DMTF). However, the times when you would use them differ significantly. This topic provides an overview of the OVF and OVA formats and why you would choose one over the other.

OVF packages contain a series of uncompressed files.

OVA packages are simply one archive file of an OVF package. OVA is useful for specific applications where it is beneficial to have just one file, such as creating packages for Web downloads.

Consider using OVA only as an option to make the package easier to handle. Using this option lengthens both the export and import processes.

Consider the following best practices when importing or exporting VMs, appliances, and disk images using the XenServer OVF Appliance Wizard:

You can use the XenServer OVF Appliance Wizard to export one or more VMs as a virtual appliance package. A VM must be shut down before exporting it. It cannot be hibernating or in a suspended state.

You can export an individual VM or all shutdown VMs in a host or pool. You can also export all shutdown VMs associated with all hosts currently connected to XenCenter.

Creating appliance packages consists of five major tasks, which you perform using the XenServer OVF Appliance Wizard:

Each task corresponds with a wizard page. Errors may appear on the Progress page if the export is unsuccessful.

The Appliance Import Wizard lets you import appliances from OVF or OVA packages. When you import the appliance, it recreates the VMs described in the package in the target location you specify. These newly recreated VMs are configured with the same resources as the original VMs.

Importing appliance packages consists of seven major tasks, which you perform with the XenServer OVF Appliance Wizard:

Each task corresponds with a wizard page. Errors may appear on the Progress page if the import is unsuccessful.

To start the Appliance Import Wizard

	Note
	Before importing OVF files, make sure all files are in the same folder and that folder is unique to the package. Importing OVF package files from multiple locations is not supported.

	Tip
	Ensure the target host has enough RAM to support the virtual machines being imported. A lack of available RAM will result in a failed import. See CTX125120 for details on how to resolve this issue.

1. Select the object in the XenCenter tree where you want the VMs in the appliance package to be located (for example, a resource pool or server).

2. Select File > Appliance Import. The Appliance Import Wizard launches.

   Where you launch the Appliance Import Wizard, determines the server that appears as the home server. For example, if you have a resource pool selected when you launch the wizard, the server that appears as Home Server is the entire pool or any individual hosts within that pool.

   This illustration shows how selecting Pool30 when you launch the Import Appliance wizard causes the wizard to specify that entire pool as its Home Server.

3. Continue selecting options in the appliance wizard. Detailed information about the choices in each page, see the XenServer OVF Appliance Wizard help in the XenCenter Help.

8.7.1. Operating System Fixups

Using OVF as a packaging method does not guarantee that VMs created with one hypervisor will be compatible with another. For example, sometimes after the initial import, VM appliances and disk images imported from non-XenServer hypervisors fail to boot correctly on XenServer.

VMs may not boot or operate correctly for a variety of reasons including different interpretations of the OVF specification, guest operating system devices, and drivers specific to a particular hypervisor.

To help resolve these issues, XenCenter includes an automatically booting ISO image known as the Operating System Fixups feature, which is an option in the XenServer OVF Appliance Wizard. XenServer OVF Appliance Import and Disk Image Import Wizards. This option is enabled by default. This option is often required when you import Windows and Linux VMs from third-party OVF packages, such as ones from VMware products. When importing XenServer or certain WIM content, enabling this option is optional.

The Operating System Fixup feature attempts to repair specific problems with the imported system that might prevent the operating system of the VM from booting. Operating System Fixups creates a basic level of interoperability for OVF packages and disk images that originated on non-XenServer platforms.

When Operating System Fixups run, XenServer OVF Appliance Import and Disk Image Import Wizards attach a bootable ISO to the DVD drive of the imported system. After import, when the VM is started, the ISO performs the repairs and then shuts down the VM. When the next time you start the VM, the VM starts normally.

The options to run Operating System Fixups appear on the following wizard pages:

Wizard	Page
Import Appliance	Select advanced import options
Disk Image Import	VM definition

Depending on the guest operating system and original hypervisor host, additional configuration changes, driver installation, or other actions may be required following using the fixup option.

	Tip
	See CTX124961, Operating System Fixup in the XenCenter 5.6 OVF Appliance Plug-in for additional troubleshooting information.

Requirements

To run Operating System Fixups, you must have an ISO SR configured at the target XenServer or XenServer pool. If you do not have an ISO SR configured, you are prompted to configure and specify one.

Note

XenServer does not support sharing a single ISO SR among many non-pooled XenServer hosts. It is preferred that your XenServer hosts are in a pool and the ISO SR is created to be used by all hosts in that pool. Importing a multi-VM OVF package into a group of non-pooled XenServer hosts may result in failed import due to the Fixup ISO not being found on each XenServer. It is important to ensure that when using non-pooled XenServer hosts, that each host has a configured ISO SR with a Fixup ISO in the ISO SR.

1. Create an NFS or CIFS (Windows) share from a file server host.

2. Have a user account that has read/write access to this share.

3. Create an ISO SR (using the user account and share from above) using the CLI or XenCenter.

The Disk Image Import wizard lets you import a disk image into one of your resource pools or into a specific host as a VM. When you import the disk image, the wizard creates a VM for it.

You might want to use this wizard when only a virtual disk image is available, and there is no OVF metadata associated with it. Situations when this might occur include:

When available, Citrix recommends importing appliance packages that contain OVF metadata and not just importing an individual disk image. The OVF data provides information the wizard needs to reconstitute a VM from its disk image, including the number of disk images associated with the VM, the processor, storage, network, and memory requirements and so on. Without this information, it can be much more complex and error-prone when trying to recreate the VM.

Importing disk images consists of two major tasks, which you perform with the XenServer Disk Image Import Wizard:

Note

Running Fixups on disk images may or may not be required. It is impossible to account for every potential device driver or other component installed and required by the original hardware platform (virtual or bare metal). In some cases, Fixups may not be able to ensure the disk imported will successfully boot as a XenServer VM. See CTX124961, Operating System Fixup in the XenCenter 5.6 OVF Appliance Plug-in for additional information regarding Fixup, operating systems and disk import types.

8.8.1. Supported disk image formats

The Disk Image Import wizard supports importing the following formats:

• Virtual Hard Disk (VHD) is a universal virtual hard-disk file format that contains items similar to a physical hard drive, such as files, folders, and partitions. Often, VHD is used as the hard disk of a virtual machine.

• Virtual Machine Disk (VMDK). The VMware virtual appliance file format for VMware products.

• Virtual Disk Image (VDI). The Oracle default storage format for Virtual Box containers.

• Windows Imaging Format (WIM). The Microsoft file-based disk image format used for its more recent operating systems (Windows 7, Windows Server 2008).

Tip

If you are importing a WIM disk image, consider reading the following Citrix Knowledge Center article: How to Build a Reference Virtual Machine for Deployment from WIM. It is important to understand that the most recent Windows versions auto-detect hardware changes and do not need to run Fixups where as Windows Server 2003 and earlier do not have this capability. In these cases, you must know what type of disk controller the WIM has to know if Fixups are required. For WIM with IDE interfaces, Fixups should not be necessary. For WIM with SCSI interfaces, Fixups are required.

When exporting and importing appliances and disk images, errors can occur for a variety of reasons. Sometimes the wizard may fail to start or errors occur after completing the wizard due to file format incompatibilities, host memory constraints, or ISO SR issues. Likewise, issues with the TransferVM template, a template specifically designed to facilitate importing and exporting VMs, may cause problems.

8.9.2. Errors after completing the wizard

The XenServer OVF Appliance Wizard writes most errors that occur during import to the XenCenter log. Consequently, the XenCenter log is a good place to begin troubleshooting.

The following errors may occur when exporting VMs and importing appliance packages or disk images:

Issue	Possible Causes	Corrective Action
OVF file is not understood	When this type of error appears, it can indicate that the wizard encountered something in the package that is non-compliant with the OVF standard.	If importing, consider importing the individual disk image files in the OVF package using the Disk Image Import wizard.
Press Cancel - doing clean up	If Cancel is pressed while importing an appliance package, the files created while attempting to import or export the appliance package are left in the destination folder (as debris) and need to be removed from the target XenServer. When Cancel is pressed, one of two things may occur: A warning may appear stating that canceling the current operations may leave the targeted VMs unusable. In some situations, if you cancel an import, XenServer might not be able to return itself to a clean state and leaves the debris. If this occurs, the VM may be left in an unusable state. If you find a virtual disk image left over from a canceled import and attempt to use it, the virtual disk image will probably be incomplete and unusable. If the import is canceled, XenServer attempts to clean up any debris remaining. This is done to leave XenServer in its pre-import state.	Delete the debris and attempt to reimport the package. If this fails, consider importing the individual disk image files in the OVF package using the Disk Image Import wizard.
Could not start Transfer VM	The TransferVM template may not be installed or may have been accidentally deleted.	Reinstall XenServer 5.6 or higher and ensure the target XenServer has local storage prior to installation.
No active sessions available	This error may occur for either of the following reasons: There are no active sessions (that is, no VMs shutdown) available for export. The TransferVM template is not installed on the host from which you are attempting to perform the action. The TransferVM template will not install unless the host has local storage.	Either shutdown the VMs you want to export or reinstall XenServer 5.6 or higher on the host, provided it has local storage.
Import Failures	The ISO SR may not contain the Fixup ISO. This may be a problem with stand alone hosts that are not in a pool trying to share the same ISO SR. XenServer does not support multiple unpooled hosts sharing the same ISO SR and the Wizard will only select from the first ISO SR it finds. An attempt to import a multi-VM OVF into two or more stand alone hosts that mount different ISO SRs.	Join hosts to a pool and mount an ISO SR. For standalone hosts that are not in a pool and that use a separate ISO SR, ensure each ISO SR has a copy of the Fixup ISO. Manually copy the Fixup ISO into the ISO SR if necessary.
WIM import blue screens with a STOP 0x0000007B Error	The fixup process was enabled against a Windows XP or Windows Server 2003 WIM with an IDE controller. The fixup process was not enabled against a Windows XP or Windows Server 2003 WIM with a SCSI controller.	Delete the imported VM, rerun Disk Import Wizard and clear the Run Fixups check box. Delete the imported VM, rerun Disk Import Wizard and check the Run Fixups check box.

	Important
	Before attempting to reimport the appliance, delete any files created during the import from the folder containing the appliance package.