January 31, 2007
The information in this Readme file pertains to Novell® ZENworks® Orchestrator, the Novell product that interacts with configuration and storage resource management servers to manage physical “compute” and “storage” resources and the relationships between them. The Orchestrator also manages virtual resources, controlling the entire lifecycle of each virtual machine.
The issues included in this document were identified when ZENworks Orchestrator was initially released. This document provides descriptions of limitations of the product or known issues and workarounds, when available. The Novell ZENworks Orchestrator 1.2 Release Notes shipped with the product include additional content that you should be aware of when setting up and using ZENworks Orchestrator. To view the Release Notes, open the Administrator Information page and click the Release Notes link.
NOTE:The Administrator Information page is available after the product is installed. For more information, see Installing the Agent and Clients from the Administrator Information Page
in the Novell ZENworks Orchestrator 1.2 Installation and Getting Started Guide. This guide also provides detailed installation instructions for the product.
This readme includes information organized in the following sections:
The following information is included in this section:
If Network File System (NFS) is used to mount a shared volume across nodes that are running the Orchestrator 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 RHEL NFS server or on a SLES NFS server, the NFS configuration is set in /etc/exports. The following configuration is needed to disable root squashing:
/auto/home *(rw,sync,no_root_squash)
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 following information is included in this section:
If you create a new VM using VM Builder GUI and you specify an ISO as the install source with a 1 GB OS Disk, the Disk Partitioner in the Yast Installation report two disks. By default, the YaST disk partitioner tries to create swap and root on the second disk. This fails because the second disk is actually the ISO install source.
To work around this issue, ignore the second disk in the partitioner and create swap and root on the 1 GB backed disk.
The following information is included in this section:
Use of the ZENworks Orchestrator Console in a firewall environment (NAT, in particular) is not supported for this release. The console uses RMI to communicate with the server, and RMI connects back to the initiator on dynamically chosen port numbers. To use the console in a firewall environment, you need to use a remote desktop or VPN product.
This section explains the issues that might occur when users use the Virtual Machine Management capabilities of ZENworks Orchestrator. The following topics are included:
VMWare* Virtual Center 2.0 introduced a new object grouping for clustering that is not supported by the VMWare API adapter currently shipping with ZENworks Orchestrator 1.1. The additional group might cause VM and host object mismatches after the Orchestrator 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 ZENworks Orchestrator to match the grouping existing in Virtual Center 2.0. After you create the group to match the group, you need to add the discovered resource to the new group and also add the new group to the for the vmhost(s) that are to be used for provisioning the resource.
If you prepare Virtual Machines that have LVM as their volume manager, on a Redhat server the default volume name is the same, so you cannot prepare a VM with LVM on a host that is also using LVM.
By default, SLES network configuration is set up with FORCE_PERSISTENT_NAMES=yes in /etc/sysconfig/network/config. This results in network device configurations being bound statically to specific MAC addresses.
MAC addresses in VMs are dynamic. In particular, if you clone a VM, you must change the MAC address so that the new VM is unique on the local network segment. If you have a SLES VM configured for DHCP with the default network configuration options, the clone does not appear on the network because its virtual NIC has a different MAC than the hard-coded configuration inside the VM image. The NIC looks like a brand new interface that isn't configured.
You can work around this issue by setting FORCE_PERSISTENT_NAMES=no in /etc/sysconfig/network/config. This setting causes the networking configuration to revert to the traditional mode of assigning eth0 to the first NIC detected by the kernel, eth1 to the second, and so on. This is the preferred mode for VMs because a VM MAC address does not remain static. In addition, a VM is likely to have only one or two virtual NICs, so eth0, eth1, etc. always refer to the same virtual NIC.
When you create a VM in the Orchestrator Console, the Virtual Disk Layout is left in an undefined state.
To work around this problem, click > to populate the virtual disk information.
The following information is included in this section:
If a VM resides in the warehouse, you will not be able to save any configuration change to that VM from the Orchestrator console. To save configuration changes, you must first provision the VM and then make configuration changes in the console, then when it is imported or checked back into the warehouse, those changes are saved.
The following information is included in this section:
If you try to suspend a Xen* VM running on a 64-bit host, the operation fails. This is a known bug with Xen tools and will be addressed in the next release of ZENworks Orchestrator.
The following issues and limitations have been identified when users are migrating a Xen VM:
An issue in the Xen virtual machine monitor incorrectly reports migration success when migrating to a host that has shared storage unmounted. This causes the VM to go into a shutdown state and return a successful error code of 0: the host does not receive the migration because the storage location is unmounted. Xen should return a different error code stating that the migration was unsuccessful.
The following limitations have been identified in a scenario where users are migrating a Xen VM:
The target machines and the source machines must have identical architecture (64-bit to 64-bit or 32-bit to 32-bit). This is automatically enforced with Constraints.
Both VM hosts (the target and the host) must have shared storage (SAN or iSCSI). This is automatically enforced with Constraints.
The operating system of the host where the VM is created must be the same OS as the host where the guest VM runs. For example, if you build a SLES VM on a RHEL machine, you can run that VM only on a RHEL machine.
The problem occurs because SLES and RHEL use different boot loaders for VM guests (SLES uses domU loader and RHEL uses pygrub). This creates a difference in the handling of the boot partition. This is not automatically enforced.
In this documentation, a greater-than symbol (>) is used to separate actions required when navigating menus in a user interface.
A trademark symbol (®, TM, 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 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.