Installation of XenServer can be accomplished in minutes using a variety of methods. Selecting the correct method will depend in part on the scale of your intended deployment and your hardware configuration. In addition to covering installation of XenServer, this chapter also covers driver management and the installation of extra components via supplemental packages.
Download the installation media from http://xenserver.org/download, and either burn it to a CD/DVD or create a bootable USB Flash device.
In a manual installation, the XenServer installation ISO is either burned to a bootable CD or copied to a bootable Flash device. The target XenServer host then boots from the installation media and can be installed. Manual installation is typically used when the number of hosts to be deployed is small, and either physical access to the host exists or access to a remote host console such as HP iLO or the Dell Remote Access Console. During a manual installation, the user will be prompted for a variety of information, but the most important configuration items relate to networking. Please refer to the section “Define Network Topologies” in Chapter 5 for more information.
Create a bootable USB key that contains the XenServer installer.
Because bootable USB devices make use of the legacy FAT32 filesystem, the ISO shipped by Citrix and available from citrix.com and xenserver.org must be converted from ISO 9660 to FAT32. The easiest tool to use for this task is Rufus. Rufus is freely available for multiple platforms and is open source. It is able to create the FAT filesystem, master boot record, and install a version of SYSLINUX, which can then be used to start the standard XenServer installer. No deep knowledge or experience with SYSLINUX is required, nor is there a requirement for a Windows or DOS bootable disk.
Follow these steps to make a bootable USB drive:
Note that Rufus defaults for cluster size and legacy BIOS alignment should be correct for most USB keys and fairly modern computers. If the USB key fails to boot correctly, decrease the cluster size to 2048 and select the advanced formatting option for legacy BIOSes. It may also be required to perform a full format of the USB stick to be successful.
XenServer supports installation via network boot. Obtain the installation media from http://xenserver.org/download and follow the instructions in the following discussion.
XenServer supports installation using network boot. In this model, a PXE or DHCP server with TFTP service available is used. The installation media is extracted from the source ISO and placed in an FTP, HTTP, or NFS location.
This discussion assumes you’ve already installed XenServer on one server and validated that no additional drivers are required. It also assumes that you’ve configured you server BIOS to be identical across all servers, and that PXE is supported on the NIC used as the management network. One key item in the preparation is that the servers are set to boot in legacy BIOS mode and not UEFI.
First, you’ll need to collect some information by doing the following:
Hostname: xenserver Root password: password Keyboard locale: us NTP server address: 0.us.pool.ntp.org DNS server address: dns.local Time zone: America/New_York Location of extracted ISO file: nfsserver:/ TFTP server IP address: pxehost
Configure the TFTP server to supply XenServer installer by following these steps. Example 7-2 contains a script that can be used to perform these steps; simply modify the XenServer ISO extract location to be where you extracted the XenServer files.
mkdir /mnt/xsinstall mount [XenServer ISO Extract Location] /mnt/xsinstall cd ./tftpboot mkdir xenserver cp /mnt/xsinstall/boot/pxelinux/mboot.c32 ./ cp /mnt/xsinstall/boot/pxelinux/pxelinux.0 ./ cp /mnt/xsinstall/install.img ./xenserver cp /mnt/xsinstall/boot/vmlinuz ./xenserver cp /mnt/xsinstall/boot/zen.gz./xenserver
In the /tftpboot/pxelinux.cfg directory, create a new configuration file called default.
Edit the default file to contain the information shown in Example 7-3. Note that this command includes remote logging to a SYSLOG server.
default xenserver-auto label xenserver-auto kernel mboot.c32 append xenserver/xen.gz dom0_max_vcpus=1-2 dom0_mem=752M,max:752M com1=115200,8n1 console=com1,vga --- xenserver/vmlinuz xencons=hvc console=hvc0 console=tty0 answerfile=http://[pxehost]/answerfile.xml remotelog=[SYSLOG] install --- xenserver/install.img
Unattended installation of XenServer requires an answer file. Place the answer file in the root directory of your NFS server (Example 7-4). Please note that there are many more options than are listed here, but the information shown in Example 7-3 will suffice for most installations.
<?xml version="1.0"?> <installation mode="fresh" srtype="lvm"> <bootloader>extlinux</bootloader> <primary-disk gueststorage="yes">sda</primary-disk> <keymap>[keyboardmap]</keymap> <hostname>[hostname]</hostname> <root-password>[password]</root-password> <source type="nfs">[XenServer ISO Extract Location]</source> <admin-interface name="eth0" proto="dhcp"/> <name-server>dns.local</name-server> <timezone>[Time zone]</timezone> <time-config-method>ntp</time-config-method> <ntp-server>[NTP Server Address]</ntp-server> <script stage="filesystem-populated" type="nfs"> [XenServer ISO Extract Location]/post-install-script.sh </script> </installation>
XenServer supports the ability to boot from a remote SAN when either a Fibre Channel or iSCSI HBA with an HBA BIOS enables the XenServer host to locate the boot media on a SAN. The following instructions assume a multipath installation is desired.
When performing a PXE-based install, the PXE configuration file will need to be modified to support device_mapper_multipath
, as shown in Example 7-5.
default xenserver-auto label xenserver-auto kernel mboot.c32 append xenserver/xen.gz dom0_max_vcpus=1-2 dom0_mem=752M,max:752M com1=115200, install --- xenserver/install.img
Some XenServer features are released as supplemental packs. A supplemental pack will contain an installer and is delivered as an ISO.
A desired feature from a supplemental pack needs to be installed.
Obtain the supplemental pack and either copy it to dom0, or place it into an ISO storage repository.
Optional XenServer components are delivered using “supplemental packs” in ISO format. A supplemental pack can contain any functionality that requires modification of dom0. Because a supplemental pack modifies dom0, it’s important to note that older supplemental packs are not supported on newer XenServer installations. Additionally, installed supplemental packs are likely to be disabled during version upgrades to ensure stable operation. In some instances, the contents of a supplemental pack have been directly incorporated into dom0, while in others, core architecture changes render the supplemental pack invalid. The latter is often the case with management agents from third parties until the third party issues a replacement supplemental pack. Installation of a supplemental pack can be done during installation but is more commonly done using the XenServer command line. Examples 7-6 and 7-7 show two different ways of installing a supplemental pack.
$ xe-install-supplemental-pack {path to ISO}
$ xe-install-supplemental-pack /var/run/sr-mount/{ISO library}/{ISO}
While a standard XenServer installation contains drivers for a large number of hardware devices, like any operating system driver disks will occasionally be required. Drivers are created using the XenServer Device Driver Kit (DDK) with the full procedure being documented in the XenServer Driver Development Kit Guide for each version of XenServer. The DDK is used by hardware vendors to create drivers for hardware that wasn’t available at the time of shipping and by Citrix support with the help of vendors to address hardware and firmware issues.
Driver disks can be required for hardware at boot time but can also be required to address performance issues in a live system.
Work with the device vendor and Citrix to obtain the correct driver for your hardware. Note that third-party driver disk development often lags behind the release of a new version of XenServer, so it’s important to verify driver availability prior to upgrading. In other words, don’t rely on a vendor proactively including previously developed drivers in updated XenServer releases.
If you needed a driver disk to install or recognize your hardware, it’s important to understand how driver disks work in a XenServer system and how they impact operational decisions. Drivers are interfaces between the physical hardware and an operating system. In the context of XenServer, they interface with the custom Linux kernel in dom0. Because a given XenServer update might include an updated Linux kernel, if you have used a custom driver, it’s important to validate if a kernel update is included. If a kernel update is part of a given XenServer update, then you will need to further validate if an updated driver exists for this new kernel. It’s not uncommon for driver updates to lag behind kernel updates for a number of reasons, so check first to minimize downtime.
When installing XenServer using an answer file, driver disks can be required to access the network and thus the answer file. In such situations, you will need to modify the XenServer installation media to include the desired driver.
If the driver isn’t required to access the answer file, the driver location can be included in the answer file using the driver-source
with a type of either nfs
or url
, as shown in Example 7-8.
<driver-source "url">ftp://[ip-address]/[driver]/</driver-source>
Occasionally, XenServer will have a default driver that is incorrectly loaded for a given hardware and prevents the driver disk contents from being used. If the installation is unattended, the driver disk contents should be added to the installer using the process described in the recipe “Slipstreaming Drivers and Supplemental Packs”. If the installation is manual, you can resolve the driver conflict using this procedure:
shell
.rmmod [driver]
where [driver]
is the name of the driver in conflict. If no error occurs, the driver has been unloaded and the conflict resolved. exit
and then supply the driver disk manually as outlined previously.Because a driver disk is really a special case of a supplemental pack, the easiest way to install a driver disk on a running system is to treat it as supplemental pack, as shown in Examples 7-9 and 7-10.
$ xe-install-supplemental-pack {path to driver ISO}
$ xe-install-supplemental-pack /var/run/sr-mount/{ISO library}/{driver ISO}
In order to ensure that all required drivers or supplemental packs are present during the installation, the installation media can be extended to include the additional items.
As mentioned previously, XenServer is extended via both driver disks and supplemental packs, both of which are delivered in supplemental pack form. Any supplemental pack can be slipstreamed into the installation media without requiring the installer itself to be modified. The following procedure will create installation media with slipstreamed features:
At this point, you will now have a XenServer installer that includes your slip-streamed features. Installation will proceed with the core XenServer binaries, and all additional features will be installed afterward.
3.135.197.201