The xen provisioning adapter job has prepackaged policies that are deployed with the job. These policies run when the job is deployed and manage the Xen hosts and VMs in the grid. The policy settings are applied to all the VMs in the grid.
For more information about the provisioning adapter policies, see Provisioning Actions Supported by the SUSE Xen Provisioning Adapter
in the NetIQ Cloud Manager 2.2.1 Component Reference.
For information about troubleshooting the xen provisioning adapter job, see Troubleshooting SUSE Xen VM Provisioning Actions
in the NetIQ Cloud Manager 2.2.1 Component Reference.
The following content describes certain Cloud Manager Orchestration Server installation and configuration defaults when it is installed in a SUSE Xen clustering environment.
A new Public JDL Library (linuxha.pylib) provides the common APIs necessary for Orchestration to interact with the SLES 11 HAE clustering stack (that is, Pacemaker).
Some minor exceptions to the behavior of SUSE Xen VMs managed by the Orchestration Server in a Pacemaker cluster include the following:
Building VMs (that is, using the VM Builder through the Orchestration Server action) is not supported in a Xen cluster. You first need to build the VMs in a non-clustered environment and then afterwards provision them to the Xen cluster.
The action is not supported for VMs running within a Xen cluster.
The , , , and (VNC console) actions are supported in the cluster only when the VM is configured to use the Xen.CMOS script. These actions are unavailable if you use the default Xen OCF script provided by the SLES 11 HAE product.
During the action, the xen provisioning adapter discovers any configured Xen clusters and models them as follows:
Creates a VmHostCluster object using the name of the clustered Orchestration Agent by default.
Discovers all nodes associated with the create VmHostCluster operation and models them as regular VM host Grid objects with the vmhost.cluster fact specified (this identifies the VM host as a member of a VmHostCluster).
Creates repositories based on file systems under the control of the clustering stack. These are resources that define the Filesystem OCF script in the cluster CIB. The provisioning adapter does not discover any shared storage that is not under control of the cluster stack. You must manually add this storage, if necessary.
When VMs are discovered (that is, when the action is executed), they are configured with a set of custom facts. These facts are stored on the VM Grid object. They are listed and described in the table below.
|
Custom Fact Name |
Description |
|---|---|
|
resource.vm.linuxha.cib_xml.id |
The unique ID of this VM as known by the cluster CIB. The fact is used as an identifier when performing actions on a VM running within a Xen Pacemaker cluster. |
|
resource.vm.linuxha.cib_xml |
The stored CIB XML definition for this VM in the cluster. When a VM is discovered (that is, when the , , or actions are executed) this fact is overwritten with new data queried from the cluster CIB. For all other actions (for example, , , etc.), the cluster’s CIB definition for the VM is replaced with the contents of this fact. |
The new xenClusterVmDefaults policy is associated by default to the VMs_xen Resource Group. The policy defines a set of default facts on a VM grid object that belongs to a Xen cluster. The facts are listed and described in the table below.
|
Fact Name |
Description |
|---|---|
|
resource.vm.linuxha.cib_xml_default |
The default CIB primitive to be used in the case where a CIB definition for this VM does not exist (that is, the VM is not defined in the cluster CIB and the value for the resource.vm.linuxha.cib_xml fact is empty). |
|
resource.vm.linuxha.clear_migrate_constraints_on_shutdown |
Used when shutting down (or restarting) the vm. If set, any location constraints created by migrate will be cleared at shutdown time. If there are specific location constraints created by an administrator, they are not cleared (unless they follow the naming convention for standard migrate constraints). |
|
resource.vm.linuxha.failcount.threshold |
Defines the allowed threshold for the failcount value used during the provisioning of a VM to a cluster. If the specified failcount threshold has been reached on all nodes in the cluster, the failcount will be reset back to 0 before attempting the start of the VM. This value can be one of: '+INFINITY', or '<Integer>'. To disable this feature, specify a value of '-1'. |
|
resource.vm.linuxha.migrate.timeout |
Timeout (in seconds) to wait for a clustered VM to reach the running state following migration. A value of 0 means wait forever. If set, this value overrides vm.linuxha.vm_state.wait.timeout (for migrate). |
|
resource.vm.linuxha.provision.timeout |
Timeout (in seconds) to wait for a clustered VM to reach the running state. A value of 0 means wait forever. If set, this value overrides vm.linuxha.vm_state.wait.timeout, and is set as the start operation timeout. |
|
resource.vm.linuxha.shutdown.timeout |
Timeout (in seconds) to wait for a clustered VM to reach the running state. A value of 0 means wait forever. if set, this value overrides vm.linuxha.vm_state.wait.timeout, and is set as the stop operation timeout and the VM’s shutdown_timeout in the CIB. To use per-VM values, set the value of this fact to the empty string (‘‘). The default is to use the value of the resource.vm.shutdown.timeout fact. |
|
resource.vm.linuxha.vm_state.wait.interval |
Defines the interval (in seconds) when the desired VM state should be re-checked (sleep interval). The default value is 5 seconds. |
|
resource.vm.linuxha.vm_state.wait.timeout |
Timeout (in seconds) to wait for a desired VM state. A value of -1 means wait forever. The default value is 120 seconds (2 min). |
The new xenClusterResource policy is associated by default to the Clusters_xen Resource Group. The policy defines a set of default facts on a Xen cluster grid object. The facts are listed and described in the table below.
|
Fact Name |
Description |
|---|---|
|
resource.linuxha.joblets.default_slots |
Specifies the default number of joblets slots to create for a Xen Cluster resource. |
|
resource.linuxha.cibadmin.cache.enabled |
If the value for this fact is true, the cluster CIB is cached when invoking queries. If the value is false, the CIB is queried directly. |
|
resource.linuxha.cibadmin.cache.lifetime |
The amount of time (in seconds) for which the cached CIB should stay valid. |
|
resource.linuxha.cibadmin.cache.invalidate_on_write |
Specifies (true or false) whether the CIB cache should be invalidated when writing to the CIB. |
Generally, the xendConfig job configures each SUSE Xen VM host (that is, it modifies /etc/xen/xend-config.sxp). The configuration includes but is not limited to the following functions:
VNC console sessions to a VM ('vnc-listen', 'vnc-passwd')
VM migration between Xen VM hosts ('xend-relocation-server' 'xend-relocation-address', 'xend-relocation-port', 'xend-relocation-hosts-allow').
Currently, when the Orchestration Agent is running in a clustered environment (that is, it is active on only one host in the cluster at a time), it is not possible to use the xendConfig job to configure all of the VM hosts contained within the Xen cluster using the xendConfig job because the agent does not have access to all hosts.
If the xendConfig job detects that it is running on a clustered VM host, the following message (or similar) is displayed:
WARNING: cluster-xenha2_xen is a member of a XEN cluster. Xend should be manually configured on this host. Skipping..
To work around this issue, manually configure the /etc/xen/xend-config.sxp file on every cluster node as appropriate, then restart the xen service (rcxend restart).
The Cloud Manager Orchestration Server extends the SUSE Xen OCF script provided with the SLES 11 HAE product. This enhanced Xen OCF script, called Xen.CMOS, resides in /usr/lib/ocf/resource.d/heartbeat/.
By modifying the resource.vm.linuxha.cib_xml fact or the resource.vm.linuxha.cib_xml_defaults fact, you can define any or all Xen VMs to use this enhanced script (the default configuration, which provides VNC session functionality and the ability to execute the , , and actions on those VMs) or you can configure them to run without this functionality by using the original Xen OCF script.
For example, in order to revert to unenhanced Xen functionality, you would change the CIB XML text from this:
<primitive class="ocf" id="sles10-pv" provider="heartbeat" type="Xen.CMOS">
to this:
<primitive class="ocf" id="sles10-pv" provider="heartbeat" type="Xen">