February 23, 2008
The information in this Readme file pertains to PlateSpin® Orchestrate from Novell®, the product that manages virtual resources and controls the entire life cycle of each virtual machine in the data center. PlateSpin Orchestrate also manages physical resources.
This document provides descriptions of limitations of the product or known issues and workarounds, when available.The issues included in this document were identified when PlateSpin Orchestrate 2.0 was initially released.
PlateSpin Orchestrate 2.0 is the latest product release of ZENworks® Orchestrator. The rebranded PlateSpin Orchestrate product is now part of the PlateSpin Workload Management product portfolio from Novell. For more details, see PlateSpin Orchestrate 2.0 Getting Started Reference.
If Network File System (NFS) is used to mount a shared volume across nodes that are running the Orchestrate Agent, the agent cannot properly set the UID on files copied from the datagrid to the managed nodes by using the default NFS configuration on most systems.
To address this problem, disable root squashing in NFS so that the agent has the necessary privileges to change the owner of the files it copies.
For example, on a Red Hat* Enterprise Linux (RHEL) NFS server or on a SUSE® Linux Enterprise Server (SLES) NFS server, the NFS configuration is set in /etc/exports. The following configuration is needed to disable root squashing:
In this example, /auto/home is the NFS mounted directory to be shared.
NOTE:The GID is not set for files copied from the datagrid to an NFS mounted volume, whether root squashing is disabled or not. This is a limitation of NFS.
The uninstall feature in YaST and YaST2 is not supported in this release of PlateSpin Orchestrate.
When you use either YaST or ZENworks Linux Management commands to upgrade ZENworks Orchestrator 1.3 components to PlateSpin Orchestrate 2.0 components on a server, the RPM packages listed after an upgrade () are labeled as version 1.3.
To work around this issue, you can use ZENworks Linux Management commands to upgrade the pattern versioning (depending on which patterns are installed) and install packages missed in the upgrade.
The following command adds packages not installed during the upgrade (avoiding an upgrade of older patterns, warehouse and orch_config) and adds the correct package version to the PlateSpin Orchestrate patterns already installed:
patterns_to_upgrade=$(rug --terse pt -i | grep zw | grep -v warehouse | grep -v orch_config | cut -d'|' -f2)
This command updates the pattern versioning:
rug in -t pattern $patterns_to_upgrade -y
IMPORTANT:For technical reasons, the orch-config package must remain at version 1.3. Do not remove this package.
Use the following command to remove the VM Warehouse package:
rug rm -t pattern zw_vm_warehouse -y
A system message is displayed:
The following packages will be removed: zw_vm_warehouse 1.3-0 (system)
Run the following command to remove the remainder of the VM Warehouse component:
rug rm novell-zenworks-vmwarehouse-base novell-zenworks-vmwarehouse-cimproviders -y
A system message is displayed:
The following packages will be removed: novell-zenworks-vmwarehouse-base 1.3.0-46 (system) novell-zenworks-vmwarehouse-cimproviders 1.3.0-27 (system)
If you use the standard command (/etc/init.d/novell-zosserver stop) to stop the PlateSpin Orchestrate prior to the upgrade, the preinstallation script detects that no snapshot was taken of the server, so it restarts the server and then stops it again to take a snapshot before upgrading the server package. If the grid has many objects, the rug command hangs during the upgrade process (that is, the rug command described in PlateSpin Orchestrate 2.0 Upgrade Guide.
In order to execute a successful upgrade, we recommend that you keep the Orchestrate Server running during the upgrade or stop it by using the --snapshot flag (for example, /etc/init.d/novell-zosserver stop --snapshot) before the upgrade.
The currently defined deployment state (that is, enabled or disabled) for a job schedule is overwritten by the default job deployment state when you upgrade from ZENworks Orchestrator 1.3 to PlateSpin Orchestrate 2.0.
If you want to re-enable or disable a job after the upgrade, you need to open the Job Scheduler in the PlateSpin Orchestrate Development Client and manually change the deployment state.
For more information, see PlateSpin Orchestrate 2.0 Development Client Reference.
Because PlateSpin Orchestrate 2.0 uses SFCB as the CIM provider for its VM Builder instead of using the OpenWBEM tool used in ZENworks Orchestrator 1.3, an upgrade from 1.3 to 2.0 causes a conflict for users who want to continue to run OpenWBEM. Both of these tools use the same port.
If you want to continue to use OpenWBEM, we recommend that you change the default TCP/IP port assigned to OpenWBEM and then make appropriate adjustments to any application that uses OpenWBEM.
The administration clients, including the zosadmin CLI tool, the Orchestrate Development Client, and the Orchestrate VM Client, communicate with the Orchestrate Server over RMI. RMI requires a correctly configured DNS service.
If you encounter connectivity problems (that is, you are unable to remotely log in to the server through these clients), verify your DNS configuration for proper hostname resolution.
In some deployments where a large number of running jobs spawn subjobs, the running jobs might appear to stop, leaving jobs in the queue. This occurs because of job limits set in the Orchestrate Server to avoid overload or “runaway” conditions.
If this deadlock occurs, you can slowly adjust the job limits to tune them according to your deployment. For more information, see PlateSpin Orchestrate 2.0 Development Client Reference.
Using the PlateSpin Orchestrate Development Client in a firewall environment (NAT, in particular) is not supported for this release. The Orchestrate Development Client uses RMI to communicate with the server, and RMI connects to the initiator on dynamically chosen port numbers. To use the Development Client in a firewall environment, you need to use a remote desktop or VPN product.
Selecting a VM Object in the Explorer tree of the PlateSpin Orchestrate Development Client opens a properties page in the workspace area of the client. One panel of this page, titledhas configuration settings that are currently nonfunctional. The feature is not implemented.
When you configure local repositories in the VM Client, the program does not check to verify that it is set up correctly on the server.
Therefore, if you create a Xen* or NAS repository and associate it with multiple hosts in the grid, move a VM into the repository, then attempt to start it, it might start on the server it resides on, start on one of the other servers sharing that repository, or not start at all.
If the VM doesn't start at all, it no longer displays in the VM Client or the Development Client, making it impossible to recover.
Workaround: Correctly set up your local repositories on your host servers, and do not share the local repositories. Allow only the host server that owns the local repository to have access to it.
When you open a log file to view it, theand buttons disappear from the bottom of the GUI.
There is currently no workaround for this issue.
You can delete the first hard disk when editing a VM, even though the other disk is an NPIV type. However, if you do this, the VM fails to work because the first disk is no an NPIV type, and this is not a supported scenario.
To work around this issue, be careful not to delete the first hard disk if the second is an NPIV type. You can also re-create the VM new with the correct disks.
If you configure a VM with None for the display driver and click to install the VM, a VNC pop-up window displays, but the VNC is never connected.
To work around this issue, be careful not to configure a VM without a display driver. You can also connect to the VM using ssh or some other utility.
After installing a VM, you cannot change the disk settings if those settings cause the installation to fail, such as making one of the disks not accessible. The Edit Wizard allows you to make changes to the disks, but the settings are not saved.
To work around this issue, create a new VM from scratch with the correct disk settings.
If you select to move a VM in the VM Client, then cancel the move in the Development Client, a Move Completed dialog box is displayed in the VM Client. However, the move does not successfully complete.
There is no workaround for this issue. Be aware that when you cancel a move operation in the Development Client, its status is not properly reflected in the VM Client.
If you plan to prepare Virtual Machines that use LVM as their volume manager on a SLES VM Host, and if that VM Host also uses LVM as its volume manager, you cannot perform the autoprep if the VM has an LVM volume with the same name as one already mounted on the VM Host. This is because LVM on the VM Host can mount only one volume with the same name.
To work around this issue, ensure that the volume names on the VM Hosts and Virtual Machines are different.
By default, when a Xen VM is provisioned or cloned, no automatic preparation of the image is performed.
However, the Info/Groups page in the Development Client might display that the autoprep network interface is configured (that is,is selected). This can be confusing and is a known issue.
To work around the issue, deselect, click the icon, re-select (if desired), then click the icon again. This causes the autoprep to occur, as setting and saving any autoprep fact causes autoprep to be performed on the new VM.
If you use the VM Builder GUI to install a new VM and you specify an ISO as the install source, the YaST disk partitioner reports two disks and might try unsuccessfully to create swap and root on the ISO image. The partitioner sees no difference between the ISO and the hard disk and attempts to partition whichever disk is larger.
To work around this problem, ignore the ISO install source shown in the partitioner and create swap and root on another storage disk.
If you manually install the Orchestrate Agent on a running VM for which there is a corresponding VM Grid Object, you must use the same name for the agent and for the Grid Object of the VM that contains the agent. If different names are used, an Under Construction flag overlays the VM icon in the Orchestrate Development Client.
This flag is used in constraints to prevent the attempted provisioning of a VM that is not yet built or that is not completely set up. The flag is cleared automatically by the provisioning adapters when names match.
If the names do not match, you need to clear the flag by manually adjusting the agent.properties file to match the names or by reinstalling the Orchestrate Agent on the VM and making sure the names match.
The following information is included in this section:
If you try to change the network configurations of virtual machine through the VCenter provisioning adapter, the settings might not be applied on virtual machines managed by VCenter 2.5 and VCenter 2.0.1
The VM templates cannot be moved across VM hosts by using the x does not allow moving VM templates across VM hosts.option through the VCenter provisioning adapter. VCenter 2.
VMware* Virtual Center 2.0 introduced a new object grouping for clustering that is not supported by the VMware API adapter currently shipping with PlateSpin Orchestrate 2.0. The additional group might cause VM and host object mismatches after the PlateSpin Orchestrate system discovers VM images in VMware Virtual Center 2.0 and when you try to provision a VM in the cluster grouping.
To work around the issue, manually create a resource group in PlateSpin Orchestrate to match the group existing in Virtual Center 2.0. After you create the group to match thegroup, you need to add the discovered resource to the new group and also add the new group to the for the VM Hosts that are to be used for provisioning the resource.
The “checkpoint” and “restore” features are not available for the Xen* provisioning adapter. The Xen hypervisor shipping in SLES 10 SP2 does not support these features.
When suspending a 32-bit fully virtualized SLES 10 SP2 VM on a 64-bit host, Xen puts the VM into an unrecoverable state that prevents freeing the loopback device, starting the Virtual Machine, or deleting the VM from the Xen host. The loopback device can be freed up only by restarting the physical machine.
This is a known Xen problem in the paravirtualized driver installed on the fully virtualized machine.
To work around this problem, remove the paravirtualized driver from the fully virtualized machine. by logging into the fully virtualized machine and removing the following package:
When this package is removed, the VM behaves as expected.
The following issues and limitations have been identified with the NPIV disks:
Do not select theoption for the NPIV disks in the Virtual Disk Editor. By default, it is not selected when you add a new NPIV disk.
Do not configure the size option for the NPIV disk in the Virtual Disk Editor. The option is not applicable for the NPIV disks and the value is always displayed as zero (0).
In this documentation, a greater-than symbol (>) is used to separate actions required when navigating menus in a user interface.
A trademark symbol (®, ™, etc.) denotes a Novell trademark; an asterisk (*) denotes a third-party trademark.
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 http://www.novell.com/info/exports/ for more information on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export approvals.
Copyright © 2008-2009 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.
Novell, Inc. has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed at http://www.novell.com/company/legal/patents and one or more additional patents or pending patent applications in the U.S. and in other countries.
For a list of Novell trademarks, see the Novell Trademark and Service Mark list at http://www.novell.com/company/legal/trademarks/tmlist.html.
All third-party products are the property of their respective owners.