Citrix XenServer ® 6.0 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 8.8, “Preparing for Cloning a Windows VM Ssing 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.

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 8.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:

This section describes the procedure to create a Windows VM from an ISO repository using the xe CLI.

At this point, the VM console will now be visible in XenCenter.

For more information on using the CLI, see Appendix A, Command Line Interface, in the XenServer Administrator's Guide.

This section shows the xe CLI procedure for creating a Linux VM, using a Debian Lenny example, by installing the OS from an internet repository.

This section shows the CLI procedure for creating a Linux VM, using a Debian Lenny example, by installing the OS from a physical CD/DVD.

This section shows the CLI procedure for creating a Linux VM, by installing the OS from network-accessible ISO.

5.3.1. Network Installation Notes

The XenServer guest installer allows you to install an operating system from a network-accessible ISO image onto a VM. To prepare for installing from an ISO, 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 E, 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. nfs://<server>/<path>

• NFS. nfs:<server>:/<path>

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

	Note
	Note that when using the NFS installation method from XenCenter, the nfs:// style of path should always be used.

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.

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

When creating a new VM, you can specify advanced operating system boot parameters using XenCenter or the xe CLI. Specifying advanced parameters may be particularly helpful if you are, for example, configuring automated installations of paravirtualized guests. For example, you might use a Debian preseed or RHEL kickstart file as follows.

To install RHEL Using a Kickstart File:

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

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/file ksdevice=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 devices, such as /dev/xvdd(or /dev/sdd in Ubuntu 10.10 and later) 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.

This section describes additional, vendor-specific configuration information that you should be aware of before creating Linux VMs. It covers each Linux distribution supported in this release of XenServer.

	Important
	For detailed release notes on all distributions, see Appendix B, Linux VM Release Notes.

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 8.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.5, “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.

XenCenter's Manage vApps dialog box allows you to create, delete and modify vApps, start and shutdown vApps, and import and export vApps within the selected pool. When you select a vApp in the list, the VMs it contains are listed in the details pane on the right.

To change the name or description of a vApp, add or remove VMs from the vApp, and change the startup sequence of the VMs in the vApp, use the Manage vApps dialog box.

See the XenCenter online help for further details. Press F1 or click Help to display the Help.

To group VMs together in a vApp follow the procedure:

	Note
	A vApp can span across multiple servers in a single pool, but cannot span across several pools.

To delete a vApp follow the procedure:

	Note
	The VMs in the vApp will not be deleted.

To start or shut down a vApp, use the Manage vApps dialog box, accessed from the Pool menu. When you start a vApp, all the VMs within it are started up automatically in sequence. The start order and delay interval values specified for each individual VM control the startup sequence; these values can be set when you first create the vApp and changed at any time from the vApp Properties dialog box or from the individual VM Properties dialog box.

vApps can be imported and exported as OVF/OVA packages. See Chapter 10, Importing and Exporting VMs for more details.

Exporting a vApp may take some time.

When the import is complete, the new vApp appears in the list of vApps in the Manage vApps dialog box.

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.

	Note
	In order to install XenServer Tools on a Windows VM, the VM must be running the Microsoft .NET Framework Version 4.0 or later. If a VM is running Windows 2003, you need to install the Windows Imaging Component (see your vendor documentation for details) before installing XenServer Tools.

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

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

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. For more information, refer to the Microsoft Knowledge Base article 314828, "The Microsoft policy for disk duplication of Windows installations".

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?

XenServer allows you to assign a physical GPU in a XenServer host machine to a Windows VM running on the same host. This GPU Pass-Through feature is intended for graphics power users, such as CAD designers, who require high performance graphics capabilities. It is supported only for use with XenDesktop.

	Important
	GPU Pass-Through is available to Citrix XenServer Enterprise editions and higher.

While XenServer supports only one GPU for each VM, it automatically detects and groups together identical physical GPUs across hosts in the same pool. Once assigned to a group of GPUs, a VM may be started on any host in the pool that has an available GPU in the group. Once attached to a GPU, a VM has certain features that are no longer available, including XenMotion live migration, VM snapshots with memory, and suspend/resume.

Assigning a GPU to a VM in a pool does not interfere with the operation of other VMs in the pool. However, VMs with GPUs attached are considered non-agile. If VMs with GPUs attached are members of a pool with HA or WLB enabled, those VMs are overlooked by both features and cannot be migrated automatically.

GPU Pass-Through is available to Windows VMs only. It can be enabled using XenCenter or the xe CLI.

Requirements

GPU Pass-Through is supported for specific machines and GPUs. In all cases, the IOMMU chipset feature (known as VT-d for Intel models) must be available and enabled on the XenServer host. Before enabling the GPU Pass-Through feature, visit www.citrix.com/ready/hcl to check the hardware compatibility list. For any further questions regarding the hardware compatibility list, e-mail xenserver.hcl@citrix.com.

Before Assigning a GPU to a VM

Before you assign a GPU to a VM, you need to put the appropriate physical GPU(s) in your XenServer host and then restart the machine. Upon restart, XenServer automatically detects any physical GPU(s). To view all physical GPU(s) across hosts in the pool, use the xe pgpu-list command.

Ensure that the IOMMU chipset feature is enabled on the host. To do so, enter the following:

xe host-param-get uuid=<uuid_of_host> param-name=chipset-info param-key=iommu

If the value printed is false, IOMMU is not enabled, and GPU Pass-Through is not available using the specified XenServer host.

	Note
	If you try to start a VM with GPU Pass-Through on a XenServer host without an available GPU in the appropriate GPU group, XenServer prints an error message.

This section lists some useful tests to carry out to ensure that your Demo Linux Virtual Appliance is correctly configured.

You can also use the web page to mount a disk.

For more information on adding virtual disks, see the XenCenter help.

Which Format to Use?

Consider using OVF/OVA format to:

Consider using XVA format to:

10.1.1. Open Virtualization Format (OVF and OVA)

OVF is an open standard, specified by the Distributed Management Task Force, for packaging and distributing a virtual appliance consisting of one or more VM(s). For further details about OVF and OVA formats, see the following:

• Knowledge Base Article CTX121652: Overview of the Open Virtualization Format

• Open Virtualization Format Specification

	Note
	In order to import or export OVF or OVA packages, you must be logged in as root or have the Pool Administrator Role Based Access Control (RBAC) role associated with your user account.

An OVF Package is the set of files that comprises the virtual appliance. It always includes a descriptor file and any other files that represent the following attributes of the package:

Attribute	Description
Descriptor (.ovf)	The descriptor always specifies the virtual hardware requirements of the package. It may also specify other information, including: Descriptions of virtual disks, the package itself, and guest operating systems A license agreement Instructions to start and stop VMs in the appliance Instructions to install the package
Signature (.cert)	The signature is the digital signature used by a public key certificate in the X.509 format to authenticate the author of the package.
Manifest (.mf)	The manifest allows you to verify the integrity of the package contents. It contains the SHA-1 digests of every file in the package.
Virtual disks	OVF does not specify a disk image format. An OVF package includes files comprising virtual disks in the format defined by the virtualization product that exported the virtual disks. XenServer produces OVF packages with disk images in Dynamic VHD format; VMware products and Virtual Box produce OVF packages with virtual disks in Stream-Optimized VMDK format.

OVF packages also support other non-metadata related capabilities, such as compression, archiving, EULA attachment, and annotations.

	Note
	When importing an OVF package that has been compressed or contains compressed files, you may need to free up additional disk space on the XenServer host in order to import it properly.

An Open Virtual Appliance (OVA) package is a single archive file, in the Tape Archive (.tar) format, containing the files that comprise an OVF Package.

10.1.1.1. Selecting OVF or OVA Format

OVF packages contain a series of uncompressed files, which makes it easier if you want to access individual disk images in the file. An OVA package contains one large file, and while you can compress this file, it does not give you the flexibility of a series of files.

Using the OVA format is useful for specific applications for which 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 format lengthens both the export and import processes.

10.1.2. Disk Image Formats (VHD and VMDK)

Using XenCenter, you can import disk images in the Virtual Hard Disk (VHD) and Virtual Machine Disk (VMDK) formats. Exporting standalone disk images is not supported.

	Note
	To import disk images, you must be logged in as root or have the Pool Administrator Role Based Access Control (RBAC) role associated with your user account.

You might choose to import a disk image when a virtual disk image is available without any associated OVF metadata. Situations in which this might occur include:

• It is possible to import a disk image, but the associated OVF metadata is not readable

• A virtual disk is not defined in an OVF package

• You are moving from a platform that does not allow you to create an OVF package (for example, older platforms or images)

• You want to import an older VMware appliance that does not have any OVF information

• You want to import a standalone VM that does not have any OVF information

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

10.1.3. XVA Format

XVA is a virtual appliance format specific to XenServer, which packages a single VM as a single set of files, including a descriptor and disk images. The filename extension is .xva.

The descriptor (file extension ova.xml) specifies the virtual hardware of a single VM.

The disk image format is a directory of files. The directory name corresponds to a reference name in the descriptor and contains 2 files for each 1 MB block of the disk image. The base name of each file is the block number in decimal. The first file contains 1 block of the disk image in raw binary format and does not have an extension. The second file is a checksum of the first file, with the extension .checksum.

	Important
	If a VM is exported from a XenServer host and then imported into another XenServer host with a different CPU type, it may not run properly. For example, a Windows VM created on a XenServer host with an Intel® VT Enabled CPU, and then exported, may not run when imported into a XenServer host with an AMD-VTM CPU.

10.1.4. XVA Version 1 Format

XVA Version 1 is the original format specific to Xen-based hypervisors for packaging an individual VM as a single file archive, including a descriptor and disk images. Its file extension is ova.xml.

The descriptor (file extension ova.xml) specifies the virtual hardware of a single VM.

The disk image format is a directory of files. The directory name corresponds to a reference name in the descriptor and contains 1 file for each 1 GB chunk of the disk image. The base name of each file includes the chunk number in decimal. It contains 1 block of the disk image in raw binary format, compressed with gzip.

	Important
	If a VM is exported from a XenServer host and then imported into another XenServer host with a different CPU type, it may not run properly. For example, a Windows VM created on a XenServer host with an Intel® VT Enabled CPU, and then exported, may not run when imported into a XenServer host with an AMD-VTM CPU.

When importing a virtual appliance or disk image created and exported from a virtualization platform other than XenServer, it may be necessary to configure or "fix up" the VM before it will boot properly on a XenServer host.

XenCenter includes an advanced hypervisor interoperability feature — Operating System Fixup — which aims to ensure a basic level of interoperability for VMs that you import into XenServer. You need to use Operating System Fixup when importing VMs from OVF/OVA packages and disk images created on other virtualization platforms.

The Operating System Fixup process addresses the operating system device and driver issues inherent when moving from one hypervisor to another, attempting to repair boot device-related problems with the imported VM that might prevent the operating system within from booting in a XenServer environment. This feature is not designed to perform conversions from one platform to another.

	Note
	This feature requires an ISO storage repository with 40 MB of free space and 256 MB of virtual memory.

Operating System Fixup is supplied as an automatically booting ISO image that is attached to the DVD drive of the imported VM. It performs the necessary repair operations when the VM is first started, and then shuts down the VM. The next time the new VM is started, the boot device is reset, and the VM starts normally.

To use Operating System Fixup on imported disk images or OVF/OVA packages, you must enable the feature on the Advanced Options page of the XenCenter Import wizard and then specify a location where the Fixup ISO should be copied so that XenServer can use it.

What Does Operating System Fixup do to the VM?

The Operating System Fixup option is designed to make the minimal changes possible to enable a virtual system to boot. Depending on the guest operating system and the hypervisor of the original host, additional configuration changes, driver installation, or other actions might be required following using the Fixup feature.

During the Fixup process, an ISO is copied to an ISO SR. The ISO is attached to a VM; the boot order is set to boot from the virtual DVD drive, and the VM boots into the ISO. The environment within the ISO then checks each disk of the VM to determine if it is a Linux or a Windows system.

If a Linux system is detected, then the location of the GRUB configuration file is determined and any pointers to SCSI disk boot devices are modified to point to IDE disks. For example, if GRUB contains an entry of /dev/sda1 representing the first disk on the first SCSI controller, this entry is changed to /dev/hda1 representing the first disk on the first IDE controller.

If a Windows system is detected, a generic critical boot device driver is extracted from the driver database of the installed operating system and registered with the operating system. This is especially important for older Windows operating systems when the boot device is changed between a SCSI and IDE interface. If certain virtualization tool sets are discovered in the VM, they are disabled to prevent performance problems and unnecessary event messages.

The Transfer VM is a built-in VM that only runs during the import or export of a virtual disk image to transfer its contents between the disk image file location and a XenServer storage repository.

One Transfer VM runs for each import or export of a disk image. When importing or exporting a virtual appliance with more than one disk image, only one disk image transfers at a time.

Running one Transfer VM has the following requirements:

The default transfer protocol is iSCSI. In which case, the Transfer VM requires an iSCSI Initiator on the XenServer host. An alternate transfer protocol is RawVDI.

	Note
	If XenCenter fails to start properly, then check that the new section group and section were added correctly.

When you import a VM, you effectively create a new VM, using many of the same steps required to provision a new VM, such as nominating a host, and configuring storage and networking.

You can import OVF/OVA, disk image, XVA and XVA Version 1 files using the XenCenter Import wizard; you can also import XVA files via the xe CLI.

10.4.1. Importing VMs from OVF/OVA

	Note
	In order to import OVF or OVA packages, you must be logged in as root or have the Pool Administrator Role Based Access Control (RBAC) role associated with your user account.

The XenCenter Import wizard allows you to import VMs that have been saved as OVF/OVA files. The Import wizard takes you through the usual steps needed to create a new VM in XenCenter: nominating a host, and then configuring storage and networking for the new VM. When importing OVF and OVA files, additional steps may be required, such as:

• When importing VMs that have been created using other virtualization platforms, it is necessary to run the Operating System Fixup feature to ensure a basic level of interoperability for the VM. For more information, see Section 10.2, “Operating System Fixup”.

• It is necessary to configure networking for the Transfer VM used to perform the import process. For more information, see Section 10.3, “The Transfer VM”.

	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.

Imported OVF packages appear as vApps when imported using XenCenter. When the import is complete, the new VMs will appear in the XenCenter Resources pane, and the new vApp will appear in the Manage vApps dialog box.

To Import VMs from OVF/OVA using XenCenter:

1. Open the Import wizard by doing one of the following:

   • In the Resources pane, right-click, and then select Import on the shortcut menu.

   • On the File menu, select Import.

2. On the first page of the wizard, locate the file you want to import, and then click Next to continue.

3. Review and accept EULAs, if applicable.

   If the package you are importing includes any EULAs, accept them and then click Next to continue. If no EULAs are included in the package, the wizard will skip this step and advance straight to the next page.

4. Specify the pool or host to which you want to import the VM(s), and then (optionally) assign the VM(s) to a home XenServer host.

   To select a host or pool, choose from the Import VM(s) to drop-down list.

   To assign each VM a home XenServer host, select a server from the list in the Home Server. If you wish not to assign a home server, select Don't assign a home server.

   Click Next to continue.

5. Configure storage for the imported VM(s): select one or more storage repositories on which to place the imported virtual disks, and then click Next to continue.

   To place all the imported virtual disks on the same SR, select Place all imported VMs on this target SR, and then select an SR from the list.

   To place the virtual disks of incoming VMs onto different SRs, select Place imported VMs on the specified target SRs. For each VM, select the target SR from the list in the SR column.

6. Configure networking for the imported VMs: map the virtual network interfaces in the VMs you are importing to target networks in the destination pool. The Network and MAC address shown in the list of incoming VMs are stored as part of the definition of the original (exported) VM in the export file. To map an incoming virtual network interface to a target network, select a network from the list in the Target Network column. Click Next to continue.

7. Specify security settings: if the selected OVF/OVA package is configured with security features, such as certificates or a manifest, specify the information necessary, and then click Next to continue.

   Different options appear on the Security page depending on which security features have been configured on the OVF appliance:

   • If the appliance is signed, a Verify digital signature check box appears, automatically selected. Click View Certificate to display the certificate used to sign the package. If the certificate appears as untrusted, it is likely that the either the Root Certificate or the Issuing Certificate Authority is not trusted on the local computer. Clear the Verify digital signature check box if you do not want to verify the signature.

   • If the appliance includes a manifest, a Verify manifest content check box appears. Select this check box to have the wizard verify the list of files in the package.

     When packages are digitally signed, the associated manifest is verified automatically, so the Verify manifest content check box does not appear on the Security page.

   	Note
   	VMware Workstation 7.1.x OVF files fail to import if you choose to verify the manifest, as VMware Workstation 7.1.x produces an OVF file with a manifest that has invalid SHA-1 hashes. If you do not choose to verify the manifest, the import is successful.

8. Enable Operating System Fixup: if the VM(s) in the package you are importing were built on a virtualization platform other than XenServer, select the Use Operating System Fixup check box and then select an ISO SR where the Fixup ISO can be copied so that XenServer can access it. For more information about this feature, see Section 10.2, “Operating System Fixup”.

   Click Next to continue.

9. Configure Transfer VM networking.

   Select a network from the list of network interfaces available in the destination pool or host, and then choose to automatically or manually configure the network settings.

   • To use automated Dynamic Host Configuration Protocol (DHCP) to automatically assign networking settings including the IP address, subnet mask and gateway, select Automatically obtain network settings using DHCP.

   • To configure networking settings manually, select Use these network settings, and then enter the required values. You must enter an IP address, but the subnet mask and gateway settings are optional.

   Click Next to continue.

10. Review the import settings, and then click Finish to begin the import process and close the wizard.

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

The import progress is displayed in the status bar at the bottom of the XenCenter window and on the Logs tab. When the newly-imported VM is available, it appears in the Resources pane, and the new vApp will appear in the Manage vApps dialog box.

10.4.3. Importing VMs from XVA

You can import VMs, templates and snapshots that have previously been exported and stored locally in XVA format (with the .xva file extension) or XVA Version 1 format (with the ova.xml file extension). To do so, you follow the usual steps needed to create a new VM: nominating a host, and then configuring storage and networking for the new VM.

	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 VM(s) from XVA Files VM using XenCenter:

1. Open the Import wizard by doing one of the following:

   • In the Resources pane, right-click, and then select Import on the shortcut menu.

   • On the File menu, select Import.

2. On the first page of the wizard, locate the file you want to import (.xva or ova.xml), and then click Next to continue.

   If you enter a URL location (http, https, file, ftp) in the Filename box, and then click Next, a Download Package dialog box opens and you must specify a folder on your XenCenter host where the file will be copied.

3. Select a pool or host for the imported VM to start on, and then choose Next to continue.

4. Select the storage repositories on which to place the imported virtual disk, and then click Next to continue.

5. Configure networking for the imported VM: map the virtual network interface in the VM you are importing to target a network in the destination pool. The Network and MAC address shown in the list of incoming VMs are stored as part of the definition of the original (exported) VM in the export file. To map an incoming virtual network interface to a target network, select a network from the list in the Target Network column. Click Next to continue.

6. Review the import settings, and then click Finish to begin the import process and close the wizard.

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

The import progress is displayed in the status bar at the bottom of the XenCenter window and on the Logs tab. When the newly-imported VM is available, it appears in the Resources pane.

To Import a VM from XVA using the xe CLI:

• To import the VM to the default SR on the target XenServer host, enter the following:

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

  To import the VM to a different SR on the target XenServer host, add 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>

  If you wish to preserve the MAC address of the original VM, add the optional preserve parameter and set to true:

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

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

Once the VM has been imported, the command prompt returns the UUID of the newly-imported VM.

You can export OVF/OVA and XVA files using the XenCenter Export wizard; you can also export XVA files via the xe CLI.

10.5.1. Exporting VMs as OVF/OVA

Using the XenCenter Export wizard, you can export one or more VM(s) as an OVF/OVA package. When you export VMs as an OVF/OVA package, the configuration data is exported along with the virtual hard disks of each VM.

	Note
	In order to export OVF or OVA packages, you must be logged in as root or have the Pool Administrator Role Based Access Control (RBAC) role associated with your user account.

To Export VM(s) as OVF/OVA using XenCenter:

1. Shut down or suspend the VM(s) that you wish to export.

2. Open the Export wizard: in the Resources pane, right-click the pool or host containing the VM(s) you want to export, and then select Export.

3. On the first page of the wizard, enter the name of the export file, specify the folder where you want the file(s) to be saved, and select OVF/OVA Package (*.ovf, *.ova) from the Format drop-down list. Click Next to continue.

4. From the list of available VMs, select the VM(s) that you want to include in the OVF/OVA package, and then click Next to continue.

5. If required, you can add to a previously-prepared End User Licensing Agreement (EULA) document (.rtf, .txt) to the package.

   To add a EULA, click Add and browse to the file you wish to add. Once you have added the file, you can view the document by selecting it from the EULA files list and then clicking View.

   EULAs can provide the legal terms and conditions for using the appliance and/or the applications delivered in the appliance.

   The ability to include one or more EULAs lets you legally protect the software on the appliance. For example, if your appliance includes a proprietary operating system on one or more of its VMs, you may want to include the EULA text from that operating system. The text is displayed and must be accepted by the person who imports the appliance.

   	Note
   	Attempting to add EULA files that are not in supported formats, including XML or binary files, can cause the import EULA functionality to fail.

   Select Next to continue.

6. On the Advanced options page, specify a manifest, signature and output file options, or just click Next to continue.

   1. To create a manifest for the package, select the Create a manifest check box.

      The manifest provides an inventory or list of the other files in a package and is used to ensure the files originally included when the package was created are the same files present when the package arrives. When the files are imported, a checksum is used to verify that the files have not changed since the package was created.

   2. To add a digital signature to the package, select the Sign the OVF package check box, browse to locate a certificate, and then enter the private key associated with the certificate in the Private key password field.

      When a signed package is imported, the user can verify the identity of the creator by using the public key to validate the digital signature. Use a X.509 certificate which you have already created from a Trusted Authority and exported as either a .pem or .pfx file that contains the signature of the manifest file and the certificate used to create that signature.

   3. To output the selected VMs as a single (tar) file in OVA format, select the Create OVA package (single OVA export file) check box. For more on the different file formats, see Section 10.1.1, “Open Virtualization Format (OVF and OVA)”.

   4. To compress virtual hard disk images (.VHD files) included in the package, select the Compress OVF files check box.

      When you create an OVF package, the virtual hard disk images are, by default, allocated the same amount of space as the exported VM. For example, a VM that is allocated 26 GB of space will have a hard disk image that consumes 26 GB of space, regardless of whether or not the VM actually requires it.

      	Note
      	Compressing the VHD files makes the export process take longer to complete, and importing a package containing compressed VHD files will also take longer, as the Import wizard must extract all of the VHD images as it imports them.

   If both the Create OVA package (single OVA export file) and Compress OVF files options are checked, the result is a compressed OVA file with the file extension .ova.gz.

7. Configure Transfer VM networking.

   Select a network from the list of network interfaces available in the destination pool or host, and then choose to automatically or manually configure the network settings.

   • To use automated Dynamic Host Configuration Protocol (DHCP) to automatically assign networking settings including the IP address, subnet mask and gateway, select Automatically obtain network settings using DHCP.

   • To configure networking settings manually, select Use these network settings, and then enter the required values. You must enter an IP address, but the subnet mask and gateway settings are optional.

   Click Next to continue.

8. Review the export settings.

   To have the wizard verify the exported package, select the Verify export on completion check box. Click Finish to begin the export process and close the wizard.

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

The export progress is displayed in the status bar at the bottom of the XenCenter window and on the Logs tab. To cancel an export in progress, click on the Logs tab, find the export in the list of events, and click the Cancel button.

10.5.1.1. Exporting VMs as XVA

You can export an existing VM as an XVA file using the XenCenter Export wizard or the xe CLI. Citrix does recommend exporting a VM to a machine other than a XenServer host, on which you can maintain a library of export files (for example, to the machine running XenCenter).

	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 Export VM(s) as XVA Files using XenCenter:

1. Shut down or suspend the VM that you wish to export.

2. Open the Export wizard: from the Resources pane, right-click the VM which you want to export, and then select Export.

3. On the first page of the wizard, enter the name of the export file, specify the folder where you want the file(s) to be saved, and select XVA File (*.xva) from the Format drop-down list. Click Next to continue.

4. From the list of available VMs, select the VM that you want to export, and then click Next to continue.

5. Review the export settings.

   To have the wizard verify the exported package, select the Verify export on completion check box. Click Finish to begin the export process and close the wizard.

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

The export progress is displayed in the status bar at the bottom of the XenCenter window and on the Logs tab. To cancel an export in progress, click on the Logs tab, find the export in the list of events, and click the Cancel button.

To Export VM(s) as XVA Files using the xe CLI:

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

2. Export the VM by running the following:

   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 later attempt to import it using XenCenter, it might fail to recognize the file as a valid XVA file.