Depending upon the
configuration of your
Cisco UCS domain, the following changes may require you to make configuration
changes after you upgrade. To avoid faults and other issues, we recommend that
you make any required changes before you upgrade.
Cisco UCS, Release 2.1(2) and Higher on Initiator IQNs Defined at the
Service Profile Level
If there are two
iSCSI vNICs and both use the same initiator IQN (which is supported in
Cisco UCS Release 2.0(1)), upgrading creates a single service profile level
initiator IQN and resets the initiator IQNs on the iSCSI vNICs to have no
If the same
initiator IQNs are used in iSCSI vNICs across service profiles in
Cisco UCS Release 2.0(1), the upgrade creates duplicate initiator IQNs at
the service profile level. This configuration generates faults for each iSCSI
vNIC that has a duplicate initiator IQN defined at the service profile level.
Changing the duplicate initiator IQNs at the service profile level clears these
faults. You must clear these faults before you perform any service profile
related operations, such as updating a host firmware package.
Maintenance Policy Should be Configured for User Acknowledgment
maintenance policy is configured to immediately reboot the server when
disruptive changes are made to the service profile, such as server firmware
upgrades through a host maintenance policy. We recommend that you change the
reboot policy setting in the default maintenance policy to user acknowledgment
to avoid unexpected disruption of server traffic.
When you configure
the reboot policy in the default maintenance policy to User Ack, the list of
disruptive changes are listed with the pending activities. You can then control
when the servers are rebooted.
VLAN IDs and Ethernet VLAN IDs Are No Longer Allowed with
Cisco UCS Release 2.0 and Higher
Cisco UCS 1.4 and earlier releases, Ethernet VLANs and FCoE VLANs could
have overlapping VLAN IDs. However, starting with
Cisco UCS release 2.0, overlapping VLAN IDs are not allowed. If
Cisco UCS Manager detects
overlapping VLAN IDs during an upgrade, it raises a critical fault. If you do
not reconfigure your VLAN IDs,
Cisco UCS Manager raises a
critical fault and drops Ethernet traffic on the overlapped VLANs. Therefore,
we recommend that you ensure there are no overlapping Ethernet and FCoE VLAN
IDs before you upgrade to
Cisco UCS Release 2.2.
Be aware that
when an uplink trunk is configured with VLAN ID 1 defined and set as the native
VLAN, changing the Ethernet VLAN 1 ID to another value can cause network
disruption and flapping on the fabric interconnects, resulting in an HA event
that introduces a large amount of traffic and makes services temporarily
If you did not
explicitly configure the FCoE VLAN ID for a VSAN in
Cisco UCS 1.4 and earlier releases,
Cisco UCS Manager assigned
VLAN 1 as the default FCoE VLAN for the default VSAN (with default VSAN ID 1).
In those releases, VLAN 1 was also used as the default VLAN for Ethernet
traffic. Therefore, if you accepted the default VLAN ID for the FCoE VLAN and
one or more Ethernet VLANs, you must reconfigure the VLAN IDs for either the
FCoE VLAN(s) on the VSAN(s) or the Ethernet VLAN(s).
For a new
Cisco UCS Release 2.2, the default VLAN IDs are as follows:
After an upgrade
Cisco UCS Release 1.4,
where VLAN ID 4048 was used for FCoE storage port native VLAN, to release 2.0,
the default VLAN IDs are as follows:
Ethernet VLAN ID is 1.
default FCoE VLAN ID is preserved.
Cisco UCS Manager raises a
critical fault on the conflicting Ethernet VLAN, if any. You must change one of
the VLAN IDs to a VLAN ID that is not used or reserved.
Cisco UCS domain uses one of the default VLAN IDs, which results in overlapping
VLANs, you can change one or more of the default VLAN IDs to any VLAN ID that
is not used or reserved. From release 2.0 and higher,
VLANs with IDs from 3968 to 4047 are reserved.
VSANs with IDs
in the Reserved Range are not Operational
A VSAN with an ID
in the reserved range is not operational after an upgrade. Make sure that none
of the VSANs configured in
Cisco UCS Manager are in
these reserved ranges:
If you plan to use FC switch mode in a Cisco UCS domain, do not configure VSANs with an ID in the range from 3040 to 4078.
If you plan to use FC end-host mode in a Cisco UCS domain, do not configure VSANs with an ID in the range from 3840 to 4079.
If a VSAN has an
ID in the reserved range, change that VSAN ID to any VSAN ID that is not used
IQN Names Must
Be Unique for Each iSCSI vNIC
Cisco UCS domain is configured for iSCSI boot, before you upgrade from
Cisco UCS, Release 2.0(1) to Release 2.0(2) or higher, you must ensure that
all iSCSI vNICs used across multiple service profiles have unique initiator
names. Changing initiator names also involves storage side configuration, which
is beyond the scope of this document.
Cisco provides a
Cisco UCS PowerTool that
identifies duplicate IQN names within a
Cisco UCS domain. For more information, see
Obtaining Cisco UCS Power
Tool and Running the Duplicate IQN Script.
If you do not ensure that all iSCSI vNICs have unique names
across all service profiles before you upgrade,
Cisco UCS Manager raises a
fault on the iSCSI vNICs to warn you that duplicate IQNs are present. Also, if
you do not ensure that there are no duplicate IQN names within a service
profile (for example, the same name used for both iSCSI vNICs),
Cisco UCS reconfigures the service profile to have a single IQN. For
information on how to clear this fault and reconfigure the duplicate IQNs, see
Cisco UCS B-Series
Impact of Upgrade from a Release Prior to Release 1.3(1i)
An upgrade from an earlier Cisco UCS firmware release to release 1.3(1i) or higher has the following impact on the Protect Configuration property of the local disk configuration policy the first time servers are associated with service profiles after the upgrade:
- Unassociated Servers
After you upgrade the Cisco UCS domain, the initial server association proceeds without configuration errors whether or not the local disk configuration policy matches the server hardware. Even if you enable the Protect Configuration property, Cisco UCS does not protect the user data on the server if there are configuration mismatches between the local disk configuration policy on the previous service profile and the policy in the new service profile.
If you enable the Protect Configuration property and the local disk configuration policy encounters mismatches between the previous service profile and the new service profile, all subsequent service profile associations with the server are blocked.
- Associated Servers
Any servers that are already associated with service profiles do not reboot after the upgrade. Cisco UCS Manager does not report any configuration errors if there is a mismatch between the local disk configuration policy and the server hardware.
When a service profile is disassociated from a server and a new service profile associated, the setting for the Protect Configuration property in the new service profile takes precedence and overwrites the setting in the previous service profile.