XenServer Driver Disks [feedly]

XenServer Driver Disks
// Latest blog entries

Why do we need them

A matter of importance for any OS to consider, is how to support hardware. One part of that support is going to be the management of device drivers used to talk to network cards, storage controllers and other such devices.

For each XenServer release, Citrix works with hardware vendors to try and get the 'latest and greatest' (and obviously stable!) drivers for supporting upcoming hardware inbox - which is for the most part great. Customers installing XenServer can successfully install XenServer on their new hardware, and they don't need to think about drivers at all.

This is all good and well except for the fact that sometimes release schedules don't align so perfectly, and actually several months after a release an OEM may start shipping a new hardware that requires updated drivers. Or perhaps a customer discovers a issue with their system which is caused by a bug in the inbox device driver.

In either case, we need a mechanism to be able to provide the customer with a new driver: enter driver disks.

What are they

A 'Driver Disk' is a particular instance of a 'Supplemental Pack' which is the mechanism that XenServer uses for supporting the installation of RPMs in Dom0.

The format of a driver disk is simply a collection of RPMs, along with some meta-data regarding the packs contents and pack dependencies (obviously RPMs include their own dependency metadata too).

These Driver disks are built by hardware vendors using the 'Driver Development Kit' (DDK) which contains a Dom0 kernel for building drivers against.

The vendor simply:

1. Creates a Makefile/specfile for generating a driver RPM.
2. Uses build-supplemental-pack.sh to compile the driver RPM, and build an ISO with the appropriate metadata.

After which the vendor can use the ISO to install the new drivers on an appropriate XenServer version. Once hardware has been certified (using our self-certification kits) with the new drivers, the vendor can go ahead and submit the drivers to Citrix who will make them available for customers to download from support.citrix.com.

Respins

The astute among you, who are familiar with the Citrix support pages may have noticed that we don't just release a single driver disk for any given XenServer release, we actually release multiple.

The reason for this is that each driver is built against a specific kernel Application Binary Interface 'ABI' - which has a particular version number. When this ABI version is bumped, because of modifications to the kernel in a kernel hotfix, the new kernel will no longer load a driver module built against the old ABI.

This is why customers might encounter the following scenario:

1. Customer installs XenServer 6.2 with driver foo x.y.z
2. Customer installs a driver disk for foo x.y.z+1
3. Customer installs a kernel hotfix
4. Customer notices that XenServer is now using foo x.y.z (!)

In this scenario, because the customer has installed a kernel hotfix on 6.2, without installing a re-spun driver disk for foo x.y.z+1, the new kernel, shipped with the kernel hotfix, will load the driver included in the GA version of 6.2. This is in order to prevent customers from having to take driver updates with kernel hotfixes.

So for each kernel hotfix, Citrix will re-spin driver disks (previously released for that product version), and post them on support.citrix.com for customers to install. This gives customers maximum flexibility in being able to choose which kernel hotfixes/drivers they want to take, independently from one another.

More info

If you want to find out more about the packaging of driver disks, or in fact how to build supplemental packs - then please checkout the official documentation here:

 

http://docs.vmd.citrix.com/XenServer/6.2.0/1.0/en_gb/supplemental_pack_ddk.html     

----
Shared via my feedly reader

Sent from my iPad