HP Virtual Connect Version 3.17 Release Notes

Resolved issues 12
• Resolved an issue found in an Integrity FlexFabric environment where the HP-UX boot path was lost
while unassigning and reassigning a profile.
• Resolved an issue for a race condition between module recovery and enclosure recovery when an
enclosure was recovering from an enclosure NO-COMM state.
• Resolved an issue when recovering from a module NO-COMM state where the correct module state is
properly tracked to avoid unnecessary failure for LANIO calls and GenNumber requests.
• Resolved an FC module firmware issue where the VC 8Gb 24-port FC module firmware version is
displayed as “Not Available" in OA, but VCM has the correct firmware version information.
• Resolved an FC module firmware issue where the DHCP client in the VC 8Gb 24-port FC module
firmware became corrupted, causing the FC module to stop responding to VCM, resulting in a
NO-COMM state.
• Resolved the restriction where the support dump could only be generated when the VC domain was in
VCEM maintenance mode. When the VC domain is under VCEM control, this restriction required the
domain to be placed in maintenance mode in order to retrieve the VCM support information. Placing
the VC domain in maintenance mode is no longer required, and if the user has VC Domain privileges,
the external VCEM manager lock is ignored and the VCM support information collection operation is
allowed.
• Resolved an issue where the GUI stated that the event manager registration was expired, and then
unexpectedly logged the user out of the GUI.
• Resolved an FC connection outage caused by a failure of the Virtual Connect FlexFabric primary
module. The failure could occur if the backup module was reset, no checkpoints or configuration
changes occurred between the primary and the backup modules, and then the primary module failed.
• Resolved two slow, small memory leaks that occurred in association with port link state changes. In
reoccurring conditions, such as a server continuously repeating a PXE boot sequence that persisted for
an extended period of days, the memory leaks would eventually result in degraded performance of the
module and an eventual module restart. One occurrence lasted for 22 days before bad module
behavior was experienced.
• Resolved an issue where a VC domain might enter into a NO-COMM state after performing an OA
failover and fail back.
• Resolved an issue associated with Private Networks when the VC-Enet network topology required server
connections to traverse an aggregated VC stacking link (one composed of multiple interfaces
aggregated together into a LAG) wherein the communication from one or more server could be lost
when the aggregation group dissolved and was reformed. This resulted from all legs of the LAG not
properly being reenabled in association with the Private Network. The servers that could experience the
disruption where those whose transmissions were distributed (load balanced) to a leg of the LAG that
was not reenabled for the Private Network.
• Resolved an issue where the stacking links showed a failed status after a module recovered from a
NO-COMM state, even though no operational problem existed. Perform a VCM reset to update the
stacking link status.
• Resolved a memory leak found in VCM during UI network reviews and profile assignments. This leak
caused VCM to restart unexpectedly when prolonged.
• An adjustment was made for the limits used by VCM in monitoring its memory utilization so as to avoid
conflict with the limits being used by the more general memory resource usage monitor for all
applications running on the module. This adjustment ensures that when memory usage exceeds an
expected, normal operational range, the VC management process can gracefully shut down. If