Other installation scenarios

Last published : Oct 01, 2026
In addition to a standard manual installation process, XenServer® provides the ability to perform various other types of installations, including the following:
  • Network installations using PXE boot
  • Unattended installations
  • Setting up the host to boot from SAN
  • Configuring host multipathing
If you encounter issues during your installation, gather the logs as described in this article: Installation logs.
Related information
Install

Supported boot modes

XenServer supports booting hosts using UEFI or UEFI Secure Boot mode. For more information on Secure Boot, see Secure Boot for XenServer 9.

Network installation

If the server that you want to install on has a PXE boot-enabled Ethernet card, you can use this feature to do a network installation with PXE boot.
Using PXE boot to install from the network involves the following steps:
Note:
PXE boot is not supported over a tagged VLAN network. Ensure that the VLAN network you use for PXE boot is untagged.

Configure your TFTP and DHCP servers

Before you set up the XenServer installation media, configure your TFTP and DHCP servers. The following sections contain information on how to configure your TFTP server for PXE boot with UEFI. Consult your vendor documentation for general setup procedures.

Configure your TFTP server for PXE boot with UEFI

Host the installer files on a TFTP server and configure your DHCP and TFTP servers to enable PXE booting with UEFI boot mode. This configuration is used to start the installation process.
  1. In the TFTP root directory (for example, /tftpboot), create a directory called EFI/xenserver.
  2. Copy the following files from the XenServer installation media to the new EFI/xenserver directory on the TFTP server:
    • grubx64.efi from the /EFI/xenserver directory
    • install.img from the root directory
    • vmlinuz from the /boot directory
    • xen.gz from the /boot directory
  3. Configure your DHCP server to provide /EFI/xenserver/grubx64.efi as the boot file.
  4. In the EFI/xenserver directory on the TFTP server, create the grub.cfg file.
    The content of this file depends on how you want to configure your PXE boot environment and on the values that are appropriate for your servers.
    • Example: Unattended install This example configuration performs an unattended installation using the answer file at the URL specified:
      menuentry "XenServer Install (serial)" {
          multiboot2 /EFI/xenserver/xen.gz dom0_max_vcpus=1-16 dom0_mem=max:8192M com1=115200,8n1 console=com1,vga
          module2 /EFI/xenserver/vmlinuz console=hvc0 console=tty0 answerfile_device=<interface_name> answerfile=http://<ip_address>/<path_to_answer_file> install
          module2 /EFI/xenserver/install.img
      }
      Note:
      To specify which network adapter to use to retrieve the answer file, include the answerfile_device=<interface_name> or answerfile_device=<MAC> parameter and specify either the network interface name (for example, eno12429np0) or the MAC address of the device.
      In environments where network adapters may be enumerated differently across hosts (for example, when using different hardware generations), you can specify the map_netdev boot parameter to explicitly control the logical ordering of network adapters based on MAC address.
      The map_netdev parameter must be supplied as an installer boot parameter and is commonly used with unattended installations to ensure consistent network adapter ordering across hosts. This parameter supports mapping a specific MAC address to logical index (e.g., map_netdev=0:<MAC>).
      To ensure a deterministic NIC order, repeat this parameter for each required adapter. For example, you can specify map_netdev=0:00:11:22:AA:BB:CC to force a specific hardware mapping.
      For more information about using an answer file, see Create an answer file for unattended installation.
    • Example: Manual install This example configuration starts an installation that boots from the TFTP server and requires manual responses:
      menuentry "XenServer Install (serial)" {
          multiboot2 /EFI/xenserver/xen.gz dom0_max_vcpus=1-16 dom0_mem=max:8192M com1=115200,8n1 console=com1,vga
          module2 /EFI/xenserver/vmlinuz console=hvc0 console=tty0
          module2 /EFI/xenserver/install.img
      }
Next step: Host your installation media on NFS, FTP, or HTTP. In addition to the TFTP and DHCP servers, you require an NFS, FTP, or HTTP server to house the XenServer files that are installed on your server.

Host your installation media on NFS, FTP, or HTTP

The TFTP server hosts the files needed to start the installer, but the files to be installed or to use for an upgrade are hosted on an NFS, FTP, or HTTP server.
You can also use files hosted on NFS, FTP, or HTTP to complete an installation or upgrade that has been started from local media on your server.
  1. On the HTTP, FTP, or NFS server, create a directory from which the XenServer installation media can be exported through HTTP, FTP, or NFS.
  2. If you are using IIS to host the installation media, assuming a virtual directory is used, complete the following set up:
    1. Enable directory browsing for the virtual directory.
    2. Ensure that double escaping is enabled for the virtual directory before extracting the installation ISO on it.
    3. Configure the following required MIME types
      1. . as an application/octet-stream
      2. .* as an application/octet-stream
      The following web.config file demonstrates these values configured for a virtual directory
      <?xml version="1.0" encoding="UTF-8"?>
      <configuration>
          <system.webServer>
              <security>
                  <requestFiltering allowDoubleEscaping="true" />
              </security>
              <directoryBrowse enabled="true" showFlags="Date, Time, Size, Extension, LongDate" />
              <staticContent>
                  <mimeMap fileExtension="." mimeType="application/octet-stream" />
                  <mimeMap fileExtension=".*" mimeType="application/octet-stream" />
              </staticContent>
          </system.webServer>
      </configuration>
  3. Unpack the contents of the XenServer installation ISO. You can do this in one of the following ways:
    • By using an ISO decompression application, such as 7-zip.
    • By mounting the ISO and copying all of the contents.
  4. Copy the entire unpacked contents of the XenServer installation ISO to the newly created directory on the HTTP, FTP, or NFS server. This directory is your installation repository.
    Note:
    When copying the XenServer installation media, ensure that you copy the file .treeinfo to the newly created directory.
Next step:

Create an answer file for unattended installation

To perform installations in an unattended fashion, create an XML answer file.
Contain all nodes within a root node named installation. When constructing your answer file, refer to the Answer file reference.
Here is an example answer file:
<?xml version="1.0"?>
    <installation srtype="ext">
        <primary-disk>sda</primary-disk>
        <guest-disk>sdb</guest-disk>
        <guest-disk>sdc</guest-disk>
        <keymap>us</keymap>
        <root-password>mypassword</root-password>
        <source type="url">http://pxehost.example.com/xenserver/</source>
        <script stage="filesystem-populated" type="url">
          http://pxehost.example.com/myscripts/post-install-script
        </script>
        <admin-interface name="<interface-name>" proto="dhcp" />
        <timezone>Europe/London</timezone>
    </installation>
Next step: Start the network installation.

Automated upgrades with an answer file

You can also perform automated upgrades by changing the answer file appropriately.
  1. Set the mode attribute of the installation element to upgrade.
  2. Specify the disk on which the existing installation lives with the existing-installation element.
  3. Leave the primary-disk and guest-disk elements unspecified.
For example:
<?xml version="1.0"?>
<installation mode="upgrade">
    <existing-installation>sda</existing-installation>
    <source type="url">http://pxehost.example.com/xenserver/</source>
    <script stage="filesystem-populated" type="url">
        http://pxehost.example.com/myscripts/post-install-script
    </script>
</installation>

Answer file reference

The following is a summary of the elements. All node values are text, unless otherwise stated. Required elements are indicated.
<installation>
Required? Yes
Description: The root element that contains all the other elements.
Attributes:
srtype
The attribute srtype can have one of the following values: lvm, ext, or xfs:
  • lvm - set the local storage type to LVM.
  • ext - set the local storage type to EXT4. This enables local caching for Citrix Virtual Desktops to work properly. For more information, see Storage.
  • xfs - set the local storage type to XFS. This option also allows you to create local storage devices with 4 KB physical blocks without requiring a logical block size of 512 bytes.
To enable thin provisioning, you can specify the srtype attribute as ext or xfs. If you do not specify the srtype attribute, the default value for srtype is lvm. If you do not specify the srtype attribute but you configure a 4 KB native disk for local storage in your answer file, the default value is xfs.
Note:
You cannot use Local LVM or Local EXT3/EXT4 storage types with 4 KB physical blocks. If you attempt to specify lvm or ext for the srtype attribute whilst configuring 4 KB physical blocks, your answer file configuration is rejected as incompatible.
mode
To change the installation type to upgrade, specify a mode attribute with the value upgrade. If this attribute is not specified, the installer performs a fresh installation and overwrites any existing data on the server.
<primary-disk>
Required? Yes
Note:
Deprecated for upgrade scenarios.
Description: The name of the storage device where the control domain is installed. This element is equivalent to the choice made on the Select Primary Disk step of the manual installation process.
Attributes: You can specify a guest-storage attribute with possible values yes and no. For example: <primary-disk guest-storage="no">sda</primary-disk>
The default value is yes. If you specify no, you can automate an installation scenario where no storage repository is created. In this case, specify no guest-disk keys.
<guest-disk>
Required? No
Description: The name of a storage device to be used for storing guests. Use one of these elements for each extra disk.
Attributes: None
<ntp>
Required? Yes
Description: Specifies the source for NTP servers. If the <ntp> element is not specified, the default shall be manual if <ntp-server> is specified, dhcp if using DHCP, otherwise default.
Attributes:
The attribute source can have one of the following values: dhcp, default, manual, or none.
  • dhcp - use NTP servers from DHCP
  • default - use default NTP servers
  • manual - use provided NTP servers, in this case at least one <ntp-server> entry must be specified
  • none - NTP is disabled
If source is dhcp, default, or none, do not specify <ntp-server>.
<ntp-server>
Required? No
Description: Specifies one or more NTP servers. To be used only with the ntp element and the attribute manual.
Attributes: None
<keymap>
Required? No
Description: The name of the key map to use during installation. <keymap>us</keymap> The default value, us is considered if you do not specify a value for this element.
Attributes: None
<root-password>
Required: No
Description: The desired root password for the XenServer host. If a password is not provided, a prompt is displayed when the host is first booted.
Attributes: You can specify a type that is either hash or plaintext
For example:
<root-password type="hash">hashedpassword</root-password>
The hashed value can use any hash type supported by crypt(3) in glibc. The default hash type is SHA-512.
You can use the following Python code to generate a hashed password string to include in the answer file:
python -c 'import crypt; print(crypt.crypt("mypasswordhere", crypt.mksalt(crypt.METHOD_SHA512)))'
<source>
Required: Yes
Description: The location of the uploaded XenServer installation media or a Supplemental Pack. This element can occur multiple times.
Attributes: The attribute type can have one of the following values: url, nfs, or local.
If the value is local, leave the element empty. For example,
<source type="url">http://server/packages</source>
<source type="local" />
<source type="nfs">server:/packages</source>
<script>
Required: No
Description: Where the post-install-script is located.
Attributes:
The attribute stage can have one of the following values: filesystem-populated, installation-start, or installation-complete.
  • When the value filesystem-populated is used, the script runs just before the root file system is unmounted (for example, after installation/upgrade, initrds already built, and so on). The script receives an argument that is the mount point of the root file system.
  • When the value installation-start is used, the script runs before starting the main installation sequence, but after the installer has initialized, and processed the answerfile. The script does not receive any arguments.
  • When the value installation-complete is used, the script runs after the installer has finished all operations (and hence the root file system is unmounted). The script receives an argument that has a value of zero if the installation completed successfully, and is non-zero if the installation failed for any reason.
The attribute type can have one of the following values: url, nfs, or local.
If the value is url or nfs, put the URL or NFS path in the PCDATA. If the value is local, leave the PCDATA empty. For example,
<script stage="filesystem-populated" type="url">
    http://prehost.example.com/post-install-script
</script>
<script stage="installation-start" type="local">
    file:///scripts/run.sh
</script>
<script stage="installation-complete" type="nfs">
    server:/scripts/installation-pass-fail-script
</script>
Note:
If a local file is used, ensure that the path is absolute. This generally means that the file:// prefix is followed by another forward slash, and then the complete path to the script.
<admin-interface>
Required: Sometimes
Note:
Required during install/reinstall but not during upgrade or restore.
Description: The single network interface to be used as the host administration interface.
Attributes:
Specify one of the following attributes:
  • name - The name of your network interface, for example eno12429np0.
  • hwaddr - The MAC address of your network interface, for example 00:00:11:aa:bb:cc.
The attribute proto can have one of the following values: dhcp or static.
If you specify proto="static", you must also specify all of these child elements:

Child elements

  • <ipaddr>: The IP address
  • <subnet>: The subnet mask
  • <gateway>: The gateway
<timezone>
Required: No
Description: The timezone in the format used by the TZ variable, for example Europe/London, or America/Los_Angeles. The default value is Etc/UTC.
<name-server>
Required: No
Description: The IP address of a nameserver. Use one of these elements for each nameserver you want to use.
<hostname>
Required: No
Description: Specify this element if you want to manually set a host name.
<ntp-server>
Required: No
Description: Specify one or more NTP servers.

Start the network installation

After setting up the network servers required for a PXE boot installation, complete the following steps on the server that you are installing onto:
  1. Start the system and enter the boot menu (F12 in most BIOS programs).
  2. Select to boot from your Ethernet card.
  3. The system then PXE boots from the installation source you set up and the installation script starts.
    • If you have set up an answer file, the installation proceeds unattended.
    • If you have decided to do a manual installation, provide information when prompted. For more information, see Install.

Boot from SAN

Boot-from-SAN environments offer several advantages, including high performance, redundancy, and space consolidation. In these environments, the boot disk is on a remote SAN and not on the local host.
The following types of boot-from-SAN configuration are supported:
Before setting up boot from SAN in XenServer, ensure that you have configured your hardware BIOS to enable this feature. Refer to your hardware vendor documentation for more information.
For a fully redundant boot-from-SAN environment, you must configure multiple paths for I/O access. For more information, see Enable multipathing.
Note:
When using a boot-from-SAN environment it is highly recommended to enable sending logs to a remote syslog server. see Send syslog messages to a central server. If remote syslog is not enabled and a system fault results in loss of access to the boot disk it can be very difficult to determine the underlying cause and Technical Support may not be able to provide assistance without these logs.

HBA and hardware Fibre Channel

This type of boot-from-SAN deployment depends on SAN-based disk arrays with either hardware Fibre Channel or HBA iSCSI adapter support on the host. The host communicates with the SAN through a host bus adapter (HBA). The HBA's BIOS contains the instructions that enable the host to find the boot disk.
All of the configuration to set up boot from SAN through hardware Fibre Channel or an HBA adapter is done in your network infrastructure before you install XenServer on your servers. For information about how to complete this set up, see the documentation provided by the vendor.

Software boot from iSCSI

The software-boot-from-iSCSI feature enables customers to install and boot XenServer from SAN using iSCSI. Using this feature, XenServer can be installed to, booted from, and run from a LUN provided by an iSCSI target. The iSCSI target is specified in the iSCSI Boot Firmware Table. This capability allows the root disk to be attached through iSCSI. This boot disk can be located on the same target that provides an SR.
To use this feature, ensure that your environment meets the following requirements:
  • The network interface or interfaces dedicated to iSCSI boot must be separate from the management interfaces and interfaces used for VM traffic.
  • Storage (iSCSI targets) must be on a separate Layer 3 (IP) network to all other network interfaces with IP addresses on the host.
  • Do not use tagged VLAN for the network interfaces dedicated to the iSCSI boot targets.
  • We recommend that you have multipathing configured.
To configure the software-boot-from-iSCSI feature, you must add the use_ibft parameter to your boot parameters. How you add this parameter depends on your boot mode and the type of installation you are doing.

Enable the software-boot-from-iSCSI feature on a UEFI boot server during an installation from local media

  1. Boot the computer from the installation media. For more information, see Install the XenServer host.
    Following the initial boot messages, you see a GRUB menu. This menu is shown for 5 seconds.
  2. Use the cursor keys to select the install option:
  3. Press the e key to edit the commands before booting.
  4. Edit the line starting with the following:
    module2 /EFI/xenserver/vmlinuz ...
    Using the cursor keys, edit this line to include use_ibft at the end:
    module2 /EFI/xenserver/vmlinuz ... use_ibft
  5. Press Enter.
  6. Continue your XenServer host installation process as normal.

Enable the software-boot-from-iSCSI feature on a UEFI boot server during a PXE boot installation

When installing using PXE, ensure that you add the keyword use_ibft in the kernel parameters.
For example:
menuentry "XenServer Install (serial)" {
    multiboot2 /EFI/xenserver/xen.gz dom0_max_vcpus=1-16 dom0_mem=max:8192M com1=115200,8n1 console=com1,vga
    module2 /EFI/xenserver/vmlinuz console=hvc0 console=tty0 answerfile_device=<interface_name> answerfile=http://<ip_address>/<path_to_answer_file> install use_ibft
    module2 /EFI/xenserver/install.img
    }
For more information about setting up PXE boot, see Configure your TFTP server for PXE boot with UEFI.

Install supplemental packs

Supplemental packs are used to modify and extend the capabilities of XenServer by installing software into the control domain (dom0). For example, an OEM partner might want to ship XenServer with a set of management tools that require SNMP agents to be installed. You can install a supplemental pack either during initial XenServer installation, or any time afterwards on a running XenServer instance.
When installing supplemental packs during XenServer installation, unpack each supplemental pack into a separate directory on a web server.
You can install the supplemental pack in one of the following ways:
  • During an interactive installation, when you are prompted to install supplemental packs, specify the URL to the supplemental pack media.
  • If you are using an answer file for your install, add an additional <source> element to specify the location of the supplemental pack.