HP Virtual Connect Version 3.17 Release Notes

Known issues 17
o
Use ports X5-X8 for SFP-DAC and SFP-LR modules when possible.
o Use the SNMP capability to capture the statistics:
— To get the switch MAC address, use the following command:
snmpwalk -c public A.B.C.D dot1dBaseBridgeAddress
— To get the port number, (X2, for example), use the following command:
snmpwalk -c public A.B.C.D ifName | grep X2
— To get the port statistics, (X2, for example), use the following command:
-c public A.B.C.D interfaces | grep 1018
o Use the GUI to view the statistics for the module. In the Uplink Port Information table on the
Interconnect Bay Summary screen, the MAC address and port displays in the Connect To column.
The SFP type displays in the Connector Type column.
• Some combinations of special characters, such as @@, #@@, #@$, (*, !@@, $!, and @@@, within the
encryption key for Configbackup might cause the CNFG write or recovery to fail. HP recommends that
you only use alphanumeric characters in the encryption key until this issue is resolved.
• When the the AssociatedNetwork Editor page contains mandatory text fields (such as VLAN id) that are
not complete, the Apply button is enabled incorrectly. This falsely indicates that the Associated Network
can be created successfully.
• If VC-Enet modules do not have assigned IP addresses (for example, the DHCP server is not responding),
a configuration change that has been made to the domain but has not been successfully checkpointed
to the backup VC-Enet module leaves the domain in a vulnerable state. If a VC failover occurs during this
state, the new primary VC-Enet module will likely clear the configuration of all of the VC-Enet modules
during recovery when the modules acquire IP addresses. Clearing the configuration of the modules
causes a networking (and FCoE) outage until the module is reconfigured by VC.
This issue is partially corrected by the serialized recovery change added for VC 3.17. For VC 3.17, the
primary VC module will not clear all of the modules at once, but will instead serialize the “left/right”
side module recovery so that a customer that has configured redundant paths to networks will not
experience a complete network outage.
To avoid this issue, ensure that the configuration has been checkpointed to the backup module before
allowing a VC failover. The VC GUI provides an indication that the checkpoint has not been completed.
A complete resolution will be provided in a future release with the “Single Command Configuration”
feature, which will allow VC to reconfigure modules without clearing the existing configuration.
• When a second enclosure is added to a VCM domain, previously configured user credentials are
erased. In this case, the default VC user ID and password must be used.
• After a VC module is reset due to error recovery, the VCM domain IP address might become
unreachable, even though the IP address for both primary and backup VC modules is still reachable. As
a solution, log in to the primary module using its IP address, uncheck the VC domain IP address, apply
the change, and then immediately recheck the VC domain IP address. This procedure will restore the
VCM domain IP address connectivity.
• A problem occurs when a change to a profile is made and applied through DCC, but the change cannot
be written to the server BIOS until the server is in a powered off state. If you power cycle the server and
attempt an additional profile change, after the server completes POST, the two updates cause the VCM
module to be reset, with a potential full reset and recovery. To avoid this problem, when making a
change to the profile, allow the next reboot to complete (not just to POST) before powering off the
server, and do not apply a profile change to the server until it has completely rebooted (not just after
POST).