NetIQ Cloud Manager 2.0 Readme

December 15, 2011

This Readme contains information about NetIQ Cloud Manager 2.0 issues you might encounter. The Readme is divided into the following sections:

1.0 Installation Issues

The following issues might be encountered during Cloud Manager installation:

1.1 Orchestration monitoring for RHEL and SLES 9 resources is not included in the installation packages

The Cloud Manager Orchestration installation media does not include the RHEL or SLES 9 monitoring packages.

If you want to monitor RHEL or SLES 9 resources, we recommend that you download Ganglia 3.1.7 from the SourceForge Web site and install it on the resources to be monitored. Create a .conf file similar to one that exists on a SLES machine, editing the node name in the file so that the monitoring metrics display for the resource in the Orchestration Console.

1.2 Orchestration Server high availability installation fails when the Cloud Manager Monitoring Server package is not installed

If you do not install the Cloud Manager Monitoring Server package during the installation of the Cloud Manager Orchestration components, later attempts to set up the server for high availability by running the script fail.

Workaround: If you intend to use the Orchestration Server in a high availability environment, you must install the Cloud Manager Monitoring Server package with it.

For information about the Cloud Manager Monitoring installation pattern, see Cloud Manager Monitoring Server Pattern in the NetIQ Cloud Manager 2.0 Installation Planning Guide.

For information about installing the Monitoring pattern in YaST, see Step 5 in the Installing the Orchestration Server to a SLES 11 Pacemaker Cluster Environmentprocedure of the NetIQ Cloud Manager 2.0 Orchestration Server High Availability Configuration Guide or Step 7 in the Installing the Orchestration Server to a SLES 10 High Availability Environment procedure of the NetIQ Cloud Manager 2.0 Orchestration Server High Availability Configuration Guide.

For information about configuring Cloud Manager Orchestration Monitoring, see Configuring the Monitoring Server and Monitoring Agent in the NetIQ Cloud Manager 2.0 Orchestration Installation Guide.

2.0 Cloud Manager Application Issues

The following issues might be encountered with the Cloud Manager Application components:

2.1 Browser becomes unresponsive when you select multiple items

If you select more than 50 items in a list and perform an action, the browser becomes unresponsive and a script error might be displayed. After a short while, the browser becomes responsive again as long as the script is not canceled.

Workaround: Select fewer than 50 items and then perform the action.

2.2 Business service workloads remain in the Building or Provision state

During the building phase of a new business service’s workload and the startup phase of a deployed workload, it is possible for the workload to be unable to be assigned to a host. This can occur when no hosts in the host group have the available resources to meet the workload resource requirements.

In the build phase, the business service remains in the Building state until a host becomes available for the workload. In the startup phase, the workload remains in the Provision state until a host becomes available.

Workaround: You have several options to resolve this issue:

  • Shut down a workload to free up the required resources on a host. If possible, select a workload that can be restarted on another host.

  • Add another host to the host group.

2.3 Cannot log in after reconfiguring the LDAP source

If you cannot log in to the Cloud Manager Application Console after using the Cloud Manager configuration utility to reconfigure the authentication source, you might have a mismatch between the e-mail address in your Cloud Manager user account and your e-mail address in the new LDAP source.

Workaround: Make sure your e-mail address in the new LDAP source matches your Cloud Manager e-mail account. Optionally, you can specify a different user and e-mail address for the initial user when you run the configuration utility, log in as that user, and then change the e-mail address in your Cloud Manager user account to match the e-mail address in the new LDAP source. You cannot run the configuration utility and enter your existing user name and the new e-mail address. The configuration utility does not update the Cloud Manager e-mail address for an existing user.

2.4 Capacity configuration setting changes do not display in Internet Explorer 9

When you run the Cloud Manager Application Console in Internet Explorer 9 and change the Capacity configuration settings, the changed settings are not reflected in the Capacity view.

Workaround: Clear the browser cache, then revisit the Capacity view.

2.5 The Capacity view displays incorrect data for an Orchestrate 2.6 zone

The Capacity view does not support data from PlateSpin Orchestrate 2.6 zones. The data that is displayed is incorrect.

Workaround: Update the zone to the Cloud Manager 2.0 Orchestration Server.

2.6 Changed business services are available in the Post-Build configuration state

A changed business service becomes available to the business service owner immediately after it is built, even though the status says that it is in a Post-Configuration state. If there are post-configuration tasks to perform on the workload, you can do so. Or, you can simply mark the Post-Configuration task as Complete.

Workaround: None.

2.7 Incorrect disk cost displayed for updated workloads

This issue applies only when you create a new business service. If you add a workload to a business service, and then edit the workload to add another disk, the workload’s displayed cost (in the business service’s Workload’s list) is not updated to include the disk cost.

Workaround: Save the business service request, then select it and click Edit to open it again. The displayed workload cost is now correct.

2.8 Unable to enter username and password in the remote console

The Cloud Manager remote console requires the keyboard encoding to be selected before the username and password can be entered.

Workaround: None. Select the keyboard encoding first, then type the username and password.

3.0 Cloud Manager Orchestration Issues

The following issues might be encountered with the Cloud Manager Orchestration components:

3.1 Admin password not being set on Windows 2003/2008 workloads

In order for a user to set the Administrator password when configuring a Windows 2003/2008 workload, the VM template (from which the workload is created) must not have an Administrator password set.

To leave the Administrator password unset on a VM template, you must turn off the complex password setting in the password policy.

3.2 The NCM_vHost policy assignment is not removed when you delete imported VMs from Cloud Manager Application Console

When a virtual machine is imported into a business service workload (in the Cloud Manager Application Console) and the workload is later deleted, the virtual machine is not deleted. This is working as designed. In addition, the NCM_vHost policy’s association with the virtual machine is not removed. Because of this, if you try to reprovision the virtual machine outside of Cloud Manager, it continues to be provisioned to the same Cloud Manager resource group.

Workaround: In the Cloud Manager Orchestration Console, remove the NCM_vHost policy from the virtual machine’s list of policies.

3.3 Orchestration Upgrade Issues

The following information is included in this section:

A clone does not inherit the policy associations of its upgraded parent VM template

When a PlateSpin Orchestrate Server is upgraded, the parent-template/clone relationship is not re-created properly. Clones do not inherit the policy associations that were created on the parent template.

Workaround: Currently, it is not possible to modify policy associations on a cloned VM in the Orchestration Server, so if the cloned VM requires these associations, you can delete the clone in the Orchestration Console, then rediscover it. After the discovery, you can apply the policies you want to this VM.

3.4 Orchestration Server Issues

The following information is included in this section:

Deploying components might fail intermittently

It is possible that when you attempt to deploy a component such as job, sjob, jdl, cfact, event, metric, policy, eaf, sar, sched, trig, python, or pylib, where prepackaged components are located in the /opt/novell/zenworks/zos/server/components directory, the Orchestration might intermittently fail the deployment, displaying a message similar to the following:

ERROR: Failed to deploy ./mem_free.<component> to <name_of_server>
     : TAP manager could not register
zos:deployer/<component>:com.novell.zos.facility.DefaultTAPManagerException: Cannot locate zos:deployer/<component> in load status.

Workaround: Restart the Orchestration Server to bring the deployer back online.

Calling terminate() from within a job class allows the JDL thread execution to continue

Calling terminate() from within the Job class does not immediately terminate the JDL thread of that job; instead, it sends a message to the server requesting termination of the job. This can take time to occur (because subjobs need to be recursively terminated and joblets cancelled), so if the calling JDL thread needs to terminate immediately, immediately follow the invocation of this method with return.

Java programs that use the JDL Exec Class might hang

Processes that are spawned by using the JDL Exec class on a Windows Orchestration Agent might hang when the spawned process attempts to read from stdin.

To work around this issue, use the following steps to turn off the enhanced ExecWrapper:

  1. In the Explorer tree of the Orchestration Console, select the job that you want to change.

  2. In the admin view of the job, select the JDL Editor tab to open the JDL Editor.

  3. Paste the following code into the editor:

    e = Exec()
  4. Save the changes.

NOTE:Disabling the enhanced ExecWrapper also makes other process control features provided as part of the ExecWrapper unavailable, such as running the process as a different user than the Orchestration Agent, or redirection of files (Exec.setStdoutFile, Exec.setStderrFile and Exec.setStrinFile).

For more information about the JDL Exec class, see the Orchestrate 2.6 JDL documentation.

3.5 vSphere VM Issues in the Orchestration Console

The following information is included in this section:

Changes to information in vSphere policies are not enforced until the vSphere Daemon is Restarted

If you change any information in a vSphere provisioning adapter policy, such as a new or additional Web address for a VCenter server, the Orchestration Server does not recognize these changes immediately.

To work around this issue, use the Job Monitor in the Orchestration Console to locate the Instance Name column of the jobs table, then find an instance named vSphere Daemon (or in the Job ID column), select this job, then click the Cancel button at the top of the monitor page.

Changes in the vSphere Provisioning Adapter job might cause errors

Testing has revealed an intermittent error when saving changes to the vSphere accounts on the vSphere provisioning adapter job. An error like this might be displayed:

Error parsing XML document: Parsing Fatal Error on Line 129, Column 6: XML
document structures must start and end within the same entity.

The error can cause a failure to save changes and prevent discovery of the vSphere environment.

Workaround: Undeploy and redeploy the vSphere provisioning adapter job in the Orchestration Console.

Undeploying the vSphere provisioning adapter removes all of the custom settings associated with it, including your account configuration and changes to the vSphere policies. We recommend that you back up or make note of the changes so that you can apply them again after you have redeployed the vSphere provisioning adapter.

3.6 Xen VM Issues in the Orchestration Console

The following information is included in this section:

Enabling a lock on a VM protects only against a second VM from provisioning

When VM locking has been enabled and a Xen VM is running on a node, then that node loses network connectivity to the Orchestration Server. As a result, reprovisioning of the VM fails because the lock is protecting the VM’s image. The VM Client indicates that the VM is down, even though the VM might still be running on the node that has been cut off.

The failed reprovisioning sends a message to the VM Client informing the user about this situation:

The VM is locked and appears to be running on <host>

The error is added to the provisioner log.

Currently, the locks protect only against a second provisioning of the VM, not against moving the VM’s image to another location. It is therefore possible to move the VM (because the Orchestration Server detects that the VM is down) and to reprovision it on another VM host.

If the original VM is still running on the cut-off VM host, this provisioning operation makes the VM crash. We recommend that you do not move the image, because unpurged, OS-level cached image settings might still exist.

The remote desktop view doesn’t work on fully virtualized Linux VMs created in SLES 11 Xen

If you try to connect to a fully virtualized Linux Xen VM by using the Orchestration Console, VM Client, or any other utility that uses vncviewer.jar, the remote view is garbled or does not stay connected.

Workaround: Use a regular VNC client or the Xen virt-viewer. You can also apply the SUSE Linux Enterprise Server 11 SP1 patch (sles11sp1-xen-201101-3749) from the Novell download site that fixes the problem in the server:

An invalid Xen vNIC model type might cause issues when a VM is managed in the Orchestration Console

Although restriction of valid vNIC types for Xen VMs occurs in the Cloud Manager VM Client, the Orchestration Console allows editing of the type (in the Constraints table under the Constraints/Facts tab of the Admin view) to any string. The Orchestration Console accepts any string as a valid vNIC type, even if it is not supported by the VM Client. In this situation, the VM can be provisioned, but it is in an unstable state, such as running indefinitely after being provisioned or being unable to launch a remote session to the VM from the Orchestration Console.

To work around this situation, you can manually shut down or remove the VM by using the xm command on the host where it was provisioned.

3.7 Hyper-V VM Issues in the Orchestration Console

The following information is included in this section:

Other ongoing issues for Hyper-V VMs are documented in The hyperv.policy File in the NetIQ Cloud Manager 2.0 VM Orchestration Reference.

Remote Console works intermittently on a Hyper-V VM host

Testing has shown that launching and using a remote console VNC session on a Hyper-V VM host from NetIQ Cloud Manager sometimes fails.

We recommend that you use the latest release of any VNC server software. If the problem persists, close the remote console window and try relaunching the remote session.

Limitations of Linux VMs as Guests on Hyper-V

The Orchestration Server does not support the Create Template or Clone actions for Linux-based Hyper-V VMs.

3.8 KVM Issues in the Orchestration Console

The following information is included in this section:

The Save Config Action does not change the vnic.model fact value

The value of the vnic.model fact on a KVM VM is not set to “virtio” by default. This might cause a slowdown in the vNIC performance for that VM.

Changing the vnic.model fact value from “hypervisor default” to “virtio” in the Orchestration Console and then performing the Save Config action does not change the value.

Workaround: Set the model for the vNIC (virtio) in the KVM virt-manager, then rediscover the VM in the Orchestration Console.