Product Description

The Xen hypervisor offers an efficient and secure feature set for virtualization of x86, x86_64, IA64, PowerPC and other CPU architectures.

A Xen system is structured with the Xen hypervisor as the lowest and most privileged layer.

Above this layer are one or more guest operating systems, which the hypervisor schedules across the physical CPUs. The first guest operating system, called in Xen terminology "domain 0" (dom0), is booted automatically when the hypervisor boots and given special management privileges and direct access to the physical hardware. The system administrator logs into dom0 in order to start any further guest operating systems, called "domain U" (domU) in Xen terminology.

Known Versions

• 2.0
• 2.0.3
• 2.0.7
• 3.0
• 3.0.4
• 3.1
• 3.2
• 4.0
• 4.1
• 4.2

Software Pattern Summary

Platforms Supported by the Pattern

The Xen Hypervisor can only be ran on modified version of Unix-like Operating Systems, the pattern identifies and models the XenSource Xenserver Server and Domains on all such Operating Systems.

Identification

Software Instance Triggers

Note: Both the XenSource XenServer Server and Domain(s) are created from the same trigger.

Xen Domain Consolidation

The consolidation of the Xen domains is handled by a separate pattern module, please click here for more information.

Simple Identification Mappings

The following processes are identified by the pattern. The identification is performed at two levels - processes listed below are identified through the use of Simple Identifiers and in addition, they are modeled within a full Software Instance for Xen Server (See Application Model Produced by Software Pattern for more details about the approach taken to model this product).

The processes there are Simple Identifiers for are:

Versioning

We currently collect version information for the product using the an Active Versioning method.

Active Versioning

The pattern checks three different files in order to obtain Version. These files contain respectively the Major, Minor and 'Extra' Version of the underlying Xen Hypervisor. The files reside in the same location, as illustrated in the table below:

The pattern extracts the version information from all three files to create the Full Version, if we extracted a value from these files then we assign the first two levels of the version to the Product Version.

Application Model Produced by Software Pattern

Product Architecture

XenServer Server runs on a modified kernel which is 'Xen-aware'. The host running this kernel is identified by Xen as Domain-0, and will always have the Xen Bus and Xen Watch processes running on it. This host provides the drivers and infrastructures that Xen requires to run its Guest Systems.

There are two Virtualization modes available on XenServer Server: Paravirtualization and Full Virtualization. While Paravirtualization requires solely a modified kernel, Full Virtualization also requires a CPU equipped with the new hardware hypervisor extensions.

Software Pattern Model

The pattern triggers on the Xen Bus process, as illustrated in Section Software Instance Triggers.

SI Depth

The pattern creates an Instance-Based (Deep) Software Instance for the XenSource XenServer Domain based on the products Domain UUID', _type and _host key.

The pattern creates an Instance-Based (Deep) Software Instance for the XenSource XenServer Server based on the products Domain UUID' (which will always be a set of 0's), _type and _host key, there has to be a XenSource server running in Domain-0 for any further Domains to run.

Domain Attributes

The pattern attempts to retrieve the following attributes:

• Domain ID
• Domain UUID
• Domain Name
• Domain State

The pattern only creates a Software Instances when it is successful in retrieving them all.

The pattern can obtain these attributes through two different methods, each either with no special privileges or with a root login or privileged access.

The pattern retrieves a list of all the domain ID's managed by XenServer Server by using an active command.

Active Command employed to obtain domain ID's: virsh list

It then iterates through the list of domain ID's and attempts to retrieve the attributes by running another Active Command on each of the domain ID's:

Active Command employed to retrieve Attributes: virsh dominfo Domain ID

If the command is successful, The pattern then parses its output through a set of Regular Expressions in order to retrieve the Attributes, as illustrated in the table below:

The pattern subsequently models a Software Instance and adds all these attributes to it.

Should the above commands fail, the pattern attempts to run a System-wide Active Command in order to retrieve the Domain Attributes.

Active Command employed to retrieve Attributes: /usr/sbin/xm list --long

Should any of the above Active Commands fail because of a lack of Privileges, the pattern may try to run it with elevated privileges.

When the Active Command is successful, the pattern splits its output into sections separated by a New Line followed by an open bracket, then parses each section by applying a set of Regular Expressions to it in order to obtain the Domain Attributes, as illustrated in the Table below:

The pattern subsequently models a Software Instance and adds all these attributes to it.

Testing

We conducted tests against live installations of XenSource XenServer Server on Linux platforms. This allowed us to ensure that the pattern correctly triggers, retrieves Domain Attributes and Versions the product using the Active method.

Information Sources

The Xen Official Page provided useful information on the Product, including Product Description and Known Versions Information.

Open Issues

There are no known open issues with this pattern.