Company
Emulex
Categories
Networks Cards
Model
Emulex LP21002
Description
OneCommand Manager Release Notes for VMware
Operating Systems
VMWare
Version Driver
7.4.0.52
Size Driver
97Kb
File Name
vmware_release_notes.pdf
Information
ESX/ESXi 4.0
Virtual Infrastructure 3 v3.5 (ESX 3.5 U4, Virtual Center 2.5) - 2, 4 & 8 Gb/s HBAs and OneConnect UCNAs
OneCommand Manager version 5.0
Release Notes
Date: January 2010
Product: OneCommand Manager™ Application for the ESX 3.5 Driver for VMware
Version: 5.0
This document describes the known issues associated with this utility build release. For the latest product documentation, go to www.emulex.com. If you have any questions or require additional information, contact an authorized Emulex Corporation technical representative.
New Features in OneCommand Manager Application Version 5.0
1. This is a new product. Refer to the OneCommand Manager Application User Manual for details.
2. Support for Emulex OneConnect™ OCe10102 UCNAs.
Resolved Issues in OneCommand Manager Application Version 5.0
1. This is a new product. There are no resolved issues.
Known Issues in OneCommand Manager Application Version 5.0
1. Remote Management FC-based (also known as in-band) remote management is not supported in this release.
Workaround: There is no workaround at this time.
2. Core Kit Upgrade Procedure The following procedure should be used to upgrade to the 5.0.18.4-1 OneCommand Manager core kit. NOTE: The upgrade process has changed for this release.
1. Remove the lpfc, be2net and (if installed) be2iscsi driver RPMs from the server.
2. Install the lpfc, be2net and (if desired) be2iscsi 2.101.411.0 driver RPMs. Do not reboot the server.
3. Upgrade to the elxocmcore-esx35-5.0.18.4-1 RPM using the “rpm –U” command.
4. Upgrade the OneConnect UCNA to the 2.101.411.0 firmware.
5. Reboot the VMware ESX 3.5 server.
3. Running the OneConnect™ FCoE Adapter without the NIC Driver It is not advised to run a OneConnect FCoE adapter without the NIC driver installed. Many management functions are unavailable:
1. Firmware
a. Download
b. Active and flash firmware versions
c. Firmware status
d. BIOS version
e. Boot code version
2. All diagnostics including beaconing
3. Transceiver data display
4. Port disable
5. Physical port link status
6. All CEE settings
7. Event log display (CLI only)
8. FAT dumps
Workaround: There is no workaround at this time.
4. CEE Priority Groups
Switching from DCBX enabled to disabled and then back to enabled may not return the Priority Groups and FCoE/iSCSI priority to the switch settings.
Workaround: Disable and re-enable the port (hbacmd setportenabled or Physical Port Info tab).
If you disable DCBX and then modify the priority groups and/or FCoE/iSCSI priority, when you enable DCBX the CEE properties will not return to the switch settings.
Workaround: Modify the priority groups and FCoE/iSCSI priority values. After they are saved, the CEE properties should match the switch.
If you disable DCBX using HBACMD (setceeparams MAC/WWPN dcbxstate 0), all Priority Group priorities and bandwidths are reset to 0. This also causes all active Priority Group priorities and bandwidths to be 0.
Workaround: Use the GUI to disable DCBX or re-enter the Priority Groups and bandwidths using the “setceepriority” and “setcnapgbw” commands. However, this workaround will cause the issue described in the previous paragraph.
5. Installation Warning Message A warning message similar to the following may appear on some systems when the RPM is installed:
ldconfig: /usr/lib/libdfc.so is not a symbolic link
This message can appear when the library configuration utility, ldconfig, encounters unexpected files in the /usr/lib/ directory. These files may exist because an earlier Emulex utility kit that does not use RPM for package management was previously installed on the system. If RPM encounters previously existing files that are not owned by RPM packages currently installed on the system, then it will save them with the ".bak" extension in the /usr/lib directory.
6. Limit Centralized Management Centralized management of adapters across VMware ESX servers must be limited to, at most, one OneCommand Manager GUI or CLI client. This applies to OneCommand Manager application remote connectivity for TCP/IP-based management.
In addition, the remote OneCommand Manager application client must be configured to disable its periodic auto-polling of discovered remote servers (which is enabled by default). This is done using the client GUI drop-down menu item shown here:
Click Discovery --> Modify Settings and select the resultant settings as follows: In-Band (Fibre Channel) - Manual Refresh Out-if-Band (TCP/IP) - Manual Refresh Expire Undiscovered HBA - Never Remove
As a result of this constraint, Emulex suggests that the OneCommand Manager application remote management of Windows, Linux, and Solaris servers take place in an environment separate from that of VMware ESX servers. It is advisable to keep the discovery domains disjointed.
Workaround: There is no workaround at this time.