This Readme contains information about NetIQ Cloud Manager 2.0 issues you might encounter. The Readme is divided into the following sections:
The following issues might be encountered during Cloud Manager installation:
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.
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 zos_server_ha_post_config.sh 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 Environment
procedure 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.
The following issues might be encountered with the Cloud Manager Application components:
Section 2.1, Browser becomes unresponsive when you select multiple items
Section 2.2, Business service workloads remain in the Building or Provision state
Section 2.3, Cannot log in after reconfiguring the LDAP source
Section 2.4, Capacity configuration setting changes do not display in Internet Explorer 9
Section 2.5, The Capacity view displays incorrect data for an Orchestrate 2.6 zone
Section 2.6, Changed business services are available in the Post-Build configuration state
Section 2.7, Incorrect disk cost displayed for updated workloads
Section 2.8, Unable to enter username and password in the remote console
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.
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 state until a host becomes available for the workload. In the startup phase, the workload remains in the 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.
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.
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.
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.
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.
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 to open it again. The displayed workload cost is now correct.
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.
The following issues might be encountered with the Cloud Manager Orchestration components:
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.
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.
The following information is included in this section:
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.
The following information is included in this section:
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 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.
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:
In the Explorer tree of the Orchestration Console, select the job that you want to change.
In the admin view of the job, select the JDL Editor tab to open the JDL Editor.
Paste the following code into the editor:
e = Exec() e.setUseJvmRuntimeExec(True)
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.
The following information is included in this section:
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 column of the jobs table, then find an instance named (or system.vspheredaemon.xxx in the column), select this job, then click the button at the top of the monitor page.
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.
The following information is included in this section:
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.
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:
32-bit download: http://download.novell.com/Download?buildid=jWavy5k3sCw~
64-bit download: http://download.novell.com/Download?buildid=yI9kZre4h7M~
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 table under the 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.
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.
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.
The Orchestration Server does not support the or actions for Linux-based Hyper-V VMs.
The following information is included in this section:
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 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.
Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes.
Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export, or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. Please refer to the Novell International Trade Services Web page for more information on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export approvals.
Copyright © 2011 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher.
For Novell trademarks, see the Novell Trademark and Service Mark list.
All third-party trademarks are the property of their respective owners.