Other installation scenarios
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
Supported boot modes
XenServer supports booting hosts using either UEFI or BIOS boot mode. UEFI Secure Boot is not currently available for XenServer hosts.
Note:
Booting XenServer hosts in BIOS mode is now deprecated. You can still install your XenServer 8 hosts in BIOS boot mode. However, doing so can prevent you from upgrading your XenServer 8 hosts to a future version of XenServer. We recommend that you install your XenServer 8 hosts by using UEFI boot mode.
The server boot mode changes how you initiate the installation process. After the installer starts, the installation process is the same for both boot modes.
When upgrading your XenServer hosts, ensure that the upgrade uses the same boot mode as the initial install.
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:
-
Copy the installer files to a TFTP server and configure your TFTP and DHCP servers for PXE boot installation. The method for doing this depends on your boot mode: BIOS or UEFI.
-
Host your installation media on NFS, FTP, or HTTP. Only the installer files are accessed from the TFTP server. The XenServer files to be installed on the server are hosted on an NFS, FTP, or HTTP server. Alternatively, after you start the install through PXE boot, you can complete it from local media hosted on the target server.
-
Create an answer file for unattended installation. You can instead choose to do an attended installation and step through the installer manually.
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 BIOS or UEFI. Consult your vendor documentation for general setup procedures.
Configure your TFTP server for PXE boot with BIOS
Note:
Booting XenServer hosts in BIOS mode is now deprecated. We recommend that you install your XenServer 8 hosts by using UEFI boot mode.
Host the installer files on a TFTP server and configure your TFTP server to enable PXE booting with BIOS boot mode. This configuration is used to start the installation process.
-
In your TFTP root directory (for example,
/tftpboot
), create a directory calledxenserver
. -
From the XenServer installation media, copy the
mboot.c32
andpxelinux.0
files from the/boot/pxelinux
directory of your installation media to the TFTP root directory.Note:
We strongly recommend using
mboot.c32
andpxelinux.0
files from the same source (for example, from the same XenServer installation ISO). -
From the XenServer installation media, copy the files to the new
xenserver
directory on the TFTP server:-
install.img
from the root directory -
vmlinuz
from the/boot
directory -
xen.gz
from the/boot
directory
-
-
In the TFTP root directory (for example,
/tftpboot
), create a directory calledpxelinux.cfg
. -
In the
pxelinux.cfg
directory, create your configuration file calleddefault
.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:
default xenserver-auto label xenserver-auto kernel mboot.c32 append xenserver/xen.gz dom0_max_vcpus=1-16 \ dom0_mem=max:8192M com1=115200,8n1 \ console=com1,vga --- xenserver/vmlinuz \ console=hvc0 console=tty0 \ answerfile=<http://pxehost.example.com/answer_file> \ answerfile_device=<device> \ install --- xenserver/install.img <!--NeedCopy-->
Note:
To specify which network adapter to use to retrieve the answer file, include the
answerfile_device=ethX
oranswerfile_device=MAC
parameter and specify either the Ethernet device number or the MAC address of the device.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:
default xenserver label xenserver kernel mboot.c32 append xenserver/xen.gz dom0_max_vcpus=1-16 \ dom0_mem=max:8192M com1=115200,8n1 \ console=com1,vga --- xenserver/vmlinuz \ console=hvc0 console=tty0 \ --- xenserver/install.img <!--NeedCopy-->
For more information about PXE configuration file contents, see the SYSLINUX website.
-
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.
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.
-
In the TFTP root directory (for example,
/tftpboot
), create a directory calledEFI/xenserver
. -
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
-
-
Configure your DHCP server to provide
/EFI/xenserver/grubx64.efi
as the boot file. -
In the
EFI/xenserver
directory on the TFTP server, create thegrub.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=eth0 answerfile=http://<ip_address>/<path_to_answer_file> install module2 /EFI/xenserver/install.img } <!--NeedCopy-->
Note:
To specify which network adapter to use to retrieve the answer file, include the
answerfile_device=ethX
oranswerfile_device=MAC
parameter and specify either the Ethernet device number or the MAC address of the device.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 } <!--NeedCopy-->
-
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 are hosted on an NFS, FTP, or HTTP server.
You can also use files hosted on NFS, FTP, or HTTP to complete an installation that has been started from local media on your server.
-
On the HTTP, FTP, or NFS server, create a directory from which the XenServer installation media can be exported through HTTP, FTP, or NFS.
-
Copy the entire contents of the XenServer installation media 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.If you are using IIS to host the installation media, ensure that double escaping is enabled on IIS before extracting the installation ISO on it.
Next step:
- If you are completing an unattended installation: Create an answer file for unattended installation.
- If you are using PXE boot to start a manual installation: Start the network installation.
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="eth0" proto="dhcp" />
<timezone>Europe/London</timezone>
</installation>
<!--NeedCopy-->
Next step: Start the network installation.
Automated upgrades with an answer file
You can also perform automated upgrades by changing the answer file appropriately.
- Set the
mode
attribute of theinstallation
element toupgrade
. - Specify the disk on which the existing installation lives with the
existing-installation
element. - Leave the
primary-disk
andguest-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>
<!--NeedCopy-->
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
orext
for thesrtype
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.
<driver-source>
Required? Yes
Description: The source of a supplemental pack containing device drivers to be loaded by the installer and included after installation of the main repository.
Attributes: None
<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>
<!--NeedCopy-->
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)))'
<!--NeedCopy-->
<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>
<!--NeedCopy-->
<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, loaded any drivers, 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>
<!--NeedCopy-->
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 exampleeth0
. -
hwaddr
- The MAC address of your network interface, for example00: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:
-
Start the system and enter the boot menu (F12 in most BIOS programs).
-
Select to boot from your Ethernet card.
-
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:
For a fully redundant boot-from-SAN environment, you must configure multiple paths for I/O access. For more information, see Enable multipathing.
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.
After your network infrastructure is correctly set up, enable multipathing on your servers during the XenServer installation process. For more information, see Enable multipathing. Proceed with the installation as normal.
Software FCoE (deprecated)
You can boot a XenServer host from an FCoE SAN by using a software FCoE stack.
For this type of boot-from-SAN deployment, before installing your XenServer host, manually complete the configuration required to expose a LUN to the host. This manual configuration includes configuring the storage fabric and allocating LUNs to the public worldwide name (PWWN) of your SAN. After you complete this configuration, the available LUN is mounted to the CNA of the host as a SCSI device. The SCSI device can then be used to access the LUN as if it were a locally attached SCSI device. When you configure the FCoE fabric, do not use VLAN 0. The XenServer host cannot find traffic that is on VLAN 0.
For information about configuring the physical switch and the array to support FCoE, see the documentation provided by the vendor.
After your network infrastructure is correctly set up, enable multipathing on your servers during the XenServer installation process. For more information, see Enable multipathing. Proceed with the installation as normal.
During a manual installation of XenServer, you are given the option on the Welcome to XenServer Setup screen to set up advanced storage classes. Press F10 and follow the instructions displayed on the screen to set up software FCoE.
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 enable multipathing on your servers.
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
-
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.
-
Use the cursor keys to select an installation option:
-
For a single path LUN, select install.
-
For a multipathed LUN, select multipath (recommended).
-
-
Press the
e
key to edit the commands before booting. -
Edit the line starting with the following:
module2 /EFI/xenserver/vmlinuz ... <!--NeedCopy-->
Using the cursor keys, edit this line to include
use_ibft
at the end:module2 /EFI/xenserver/vmlinuz ... use_ibft <!--NeedCopy-->
-
Press Enter.
-
Continue your XenServer host installation process as normal.
Enable the software-boot-from-iSCSI feature on a BIOS boot server during an installation from local media
Note:
Booting XenServer hosts in BIOS mode is now deprecated. We recommend that you install your XenServer 8 hosts by using UEFI boot mode.
-
Boot the computer from the installation media. For more information, see Install the XenServer host.
Following the initial boot messages, you see the Welcome to XenServer screen.
-
At the boot prompt, enter
menu.c32
. -
Use the cursor keys to select an installation option:
-
For a single path LUN, select install.
-
For a multipathed LUN, select multipath.
-
-
Press the tab key.
-
Edit the line ending with the following:
--- /install.img <!--NeedCopy-->
Using the cursor keys, edit this line to read:
use_ibft --- /install.img <!--NeedCopy-->
-
Press Enter.
-
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. If multipathing is required, you must add device_mapper_multipath=enabled.
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=eth0 answerfile=http://<ip_address>/<path_to_answer_file> install use_ibft device_mapper_multipath=enabled
module2 /EFI/xenserver/install.img
}
<!--NeedCopy-->
For more information about setting up PXE boot, see Configure your TFTP server for PXE boot with UEFI.
Enable the software-boot-from-iSCSI feature on a BIOS boot server during a PXE boot installation
Note:
Booting XenServer hosts in BIOS mode is now deprecated. We recommend that you install your XenServer 8 hosts by using UEFI boot mode.
When installing using PXE, ensure that you add the keyword use_ibft in the kernel parameters. If using multipathing (recommended) you must add device_mapper_multipath=enabled.
For example:
default xenserver-auto
label xenserver-auto
kernel mboot.c32
append xenserver/xen.gz dom0_max_vcpus=1-16 \
dom0_mem=max:8192M com1=115200,8n1 \
console=com1,vga --- xenserver/vmlinuz \
console=hvc0 console=tty0 \
answerfile=<http://pxehost.example.com/answer_file> \
answerfile_device=<device> \
use_ibft device_mapper_multipath=enabled --- xenserver/install.img
<!--NeedCopy-->
For more information about setting up PXE boot, see Configure your TFTP server for PXE boot with BIOS.
Enable multipathing
For a fully redundant boot-from-SAN environment, you must configure multiple paths for I/O access. To do so, ensure that the root device has multipath support enabled.
For information about whether multipath is available for your SAN environment, consult your storage vendor or administrator.
Warning:
Multipath settings are not inherited during the upgrade process. When upgrading using the ISO or network boot, follow the same instructions as used in the following installation process to ensure that
multipath
is correctly configured.
If you have multiple paths available, enable multipathing in your XenServer deployment while initializing the installation process. How you enable multipathing depends on your boot mode and the type of installation you are doing.
Enable multipathing on a UEFI boot server during a manual installation
-
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.
-
On the GRUB menu, choose
multipath
and press Enter.
The XenServer installation process configures the XenServer host, which boots from a remote SAN with multipathing enabled.
Enable multipathing on a BIOS boot server during a manual installation
Note:
Booting XenServer hosts in BIOS mode is now deprecated. We recommend that you install your XenServer 8 hosts by using UEFI boot mode.
-
Boot the computer from the installation media. For more information, see Install the XenServer host.
Following the initial boot messages, you see the Welcome to XenServer screen.
-
At the welcome screen, press F2 to select Advanced install.
-
At the boot prompt, enter
multipath
.
The XenServer installation process configures the XenServer host, which boots from a remote SAN with multipathing enabled.
Enable multipathing on a UEFI boot server during an unattended installation
To enable file system multipathing during PXE installation, add device_mapper_multipath=enabled
to your configuration file.
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=eth0 answerfile=http://<ip_address>/<path_to_answer_file> install use_ibft device_mapper_multipath=enabled
module2 /EFI/xenserver/install.img
}
<!--NeedCopy-->
For more information about setting up PXE boot, see Configure your TFTP server for PXE boot with UEFI.
Enable multipathing on a BIOS boot server during an unattended installation
Note:
Booting XenServer hosts in BIOS mode is now deprecated. We recommend that you install your XenServer 8 hosts by using UEFI boot mode.
To enable file system multipathing during PXE installation, add device_mapper_multipath=enabled
to your configuration file.
For example:
default xenserver-auto
label xenserver-auto
kernel mboot.c32
append xenserver/xen.gz dom0_max_vcpus=1-16 \
dom0_mem=max:8192M com1=115200,8n1 \
console=com1,vga --- xenserver/vmlinuz \
console=hvc0 console=tty0 \
answerfile=<http://pxehost.example.com/answer_file> \
answerfile_device=<device> \
device_mapper_multipath=enabled \
install --- xenserver/install.img
<!--NeedCopy-->
For more information about setting up PXE boot, see Configure your TFTP server for PXE boot with BIOS.
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.
Install driver disks
You can install a driver disk using one of the following methods:
- By using XenCenter (recommended)
- During a clean XenServer installation
- By using the xe CLI
For information on how to install a driver disk by using XenCenter, see Install driver disks. For information on how to install a driver disk during a clean XenServer installation, see Install the XenServer host.
After installing the driver, restart your server for the new version of the driver to take effect. As with any software update, we advise you to back up your data before installing a driver disk.
Install a driver disk by using the xe CLI
Perform the following steps to install the driver disk remotely using the xe CLI:
-
Download the driver disk to a known location on a computer that has the remote xe CLI installed.
-
Extract the contents of the zip file.
For the next step, ensure that you use the driver ISO and not the ISO that contains the source files.
-
Upload the driver disk:
xe [connection_parameters] update-upload file-name= <!--NeedCopy-->
The UUID of the driver disk is returned when the upload completes.
-
Apply the driver disk:
xe [connection_parameters] update-apply uuid= <!--NeedCopy-->
-
To complete the installation, restart the host. The driver does not take effect until after the host is restarted.