Cisco UCS Manager B-Series Troubleshooting Guide
Troubleshooting Issues with Cisco UCS Manager
Download the complete book
Cisco UCS Manager B-Series Troubleshooting GuideCisco UCS Manager B-Series Troubleshooting Guide (PDF - 2 MB)
 Feedback

Contents

Troubleshooting Issues with Cisco UCS Manager

This chapter includes the following sections:

Troubleshooting Boot Issues

Reboot Warning Does Not Display

Problem—The system fails to produce a reboot warning that lists any dependencies.

Possible Cause—This problem can be caused by changes to a vNIC template or a vHBA template. Reboot warnings occur when the back-end returns a list of dependencies. When you update the template type for a vNIC or vHBA template and make changes to any boot-related properties without applying changes between steps, the back-end systems are not triggered to return a list of dependencies.

Procedure
    Step 1   Launch the Cisco UCS Manager GUI.
    Step 2   In the vNIC template or vHBA template included in the service profile, do the following:
    1. Change the template type from Initial Template to Updating Template.
    2. Click Save Changes.
    Step 3   Make any additional changes to the reboot-related values and click Save Changes.

    A reboot warning and the list of dependencies are displayed.

    Server Does Not Boot from OS Installed on eUSB

    Problem—The eUSB embedded inside the Cisco UCS server includes an operating system. However, the server does not boot from that operating system.

    Possible Cause—This problem can occur when, after associating the server with the service profile, the eUSB is not at the top of the actual boot order for the server.

    Procedure
      Step 1   Launch the Cisco UCS Manager GUI.
      Step 2   On the Servers tab, do the following to verify the boot policy configuration:
      1. Navigate to the service profile associated with the server.
      2. In the Work pane, click the Boot Order tab
      3. Ensure that Local Disk is configured as the first device in the boot policy.
      Step 3   On the Equipment tab, do the following to verify the actual boot order for the server:
      1. Navigate to the server.
      2. On the General tab, expand the Boot Order Details area and verify that the eUSB is listed as the first device on the Actual Boot Order tab.

        For example, the first device should be VM eUSB DISK.

      Step 4   If the eUSB is not the first device in the actual boot order, do the following:
      1. On the General tab for the server, click the following links in the Actions area:
        • Click KVM Console to launch the KVM console.
        • Click Boot Server to boot the server.
      2. In the KVM console, while the server is booting, press F2 to enter the BIOS setup.
      3. In the BIOS utility, click on the Boot Options tab.
      4. Click Hard Disk Order.
      5. Configure Boot Option #1 to the eUSB.

        For example, set this option to VM eUSB DISK.

      6. Press F10 to save and exit.

      Server Does Not Boot After RAID1 Cluster Migration

      Problem—The server does not boot from the operating system after a RAID1 cluster migration. The RAID LUN remains in “inactive” state during and after service profile association. As a result, the server cannot boot.

      Possible Cause—This problem can occur if the local disk configuration policy in the service profile on the server is configured with Any Configuration mode rather than RAID1.

      Procedure
        Step 1   In Cisco UCS Manager GUI, click the Servers tab.
        Step 2   Navigate to the service profile associated with the server and click the Storage tab.
        Step 3   Do one of the following:

        • Change the local disk configuration policy included in the service profile to the same policy included in the service profile associated with the server prior to the migration, as follows:

          • In the Actions area, click Change Local Disk Configuration Policy.
          • From the Select the Local Disk Configuration Policy drop-down list, choose the appropriate policy.
          • Click OK.

        • Change the mode property in the local disk configuration policy included in the service profile, as follows:

          • In the Local Disk Configuration Policy area of the Storage tab, click the link in the Local Disk Policy Instance field.
          • In the Mode field, ensure that the Raid 1 Mirrored option is chosen.
          • Click Save Changes.

        Troubleshooting KVM Issues

        BadFieldException When Launching the KVM Viewer

        Problem—The BadFieldException error appears when the KVM viewer is launched.

        Possible Cause—This problem can occur because the Java Web Start disables the cache by default when it is used with an application that uses native libraries.

        Procedure
          Step 1   Choose Start > Control Panel > Java.
          Step 2   Click on the General tab.
          Step 3   In the Temporary Internet Files area, click Settings.
          Step 4   Click the Keep temporary files on my computer check box.
          Step 5   Click OK.

          KVM Console Failure

          Problem—The KVM console fails to launch and the JRE displays the following message: 

          Unable to launch the application.

          Possible Cause—This problem can be caused if several KVM consoles are launched simultaneously.

          Procedure
            Step 1   If possible, close all of the open KVM consoles.
            Step 2   Relaunch the KVM consoles one at a time.

            KVM Fails to Open

            Problem—The first time you attempt to open the KVM on a server, the KVM fails to launch.

            Possible Cause—This problem can be caused by a JRE version incompatibility.

            Procedure
              Step 1   Upgrade to JRE 1.6_11.
              Step 2   Reboot the server.
              Step 3   Launch the KVM console.

              Troubleshooting VM issues

              No Ports Available for Distributed Virtual Switch

              Problem—The following error displays: 

              Currently connected network interface x uses Distributed Virtual Switch (uusid:y) which is 
accessed on the host via a switch that has no free ports.

              Possible Cause—This problem can be caused by one of the following issues:

              • After powering off or migrating a VM from one host to another, the vSphere server fails to recompute the numPortsAvailable property in the hostProxySwitch object.
              • The cumulative number of vNICs for the VMs powered on an ESX host matches or exceeds the number of dynamic nVINCs configured in the server’s service profile.
              • After migrating a VM from one data-store to another data-store on the same server, the server incorrectly detects an increase in the number of DVS ports being used by all of the VMs powered on the host.
              Procedure
                 Command or ActionPurpose
                Step 1Identify what you were doing when the error displayed.   
                Step 2If the error resulted from powering off a VM, or from migrating a VM from one host to another, do the following:    
                Step 3If the error resulted from migrating a VM instance from one data-store to another data-store on the same server, do the following:    

                Troubleshooting Cisco UCS Manager Issues

                Event Sequencing Fatal Error

                Problem—After coming back from sleep mode, the Cisco UCS Manager GUI displays the following message:

                Fatal error: event sequencing is skewed.

                Possible Cause—This problem can be caused if the Cisco UCS Manager GUI was running when the computer went to sleep. Since the JRE does not have a sleep detection mechanism, the system is unable to retrack all of the messages received before it went into sleep mode. After multiple retries, this event sequencing error is logged.


                Note

                Always shut down Cisco UCS Manager GUI before putting your computer to sleep.

                Procedure
                In Cisco UCS Manager GUI, if a Connection Error dialog box is displayed, click one of the following:
                • Click Re-login to log back in to the Cisco UCS Manager GUI.
                • Click Exit to exit the Cisco UCS Manager GUI.

                Troubleshooting Fabric Interconnect Issues

                Recovering a Fabric Interconnect from the Boot Loader Prompt

                If the fabric interconnect fails to start, you may have one of the following issues:

                • The kickstart image is corrupted or non-functional for other reasons
                • The file system on the bootflash memory is corrupted

                If either of these issues exist, you might need to use the boot loader prompt to recover the fabric interconnect.

                Procedure
                Contact Cisco TAC to obtain the firmware recovery images and information about how to recover the fabric interconnect from the boot loader prompt.

                Resolving Fabric Interconnect Cluster ID Mismatch

                Problem—When you set up two fabric interconnects to support a high availability cluster and connect the L1 ports and L2 ports, a fabric interconnect cluster ID mismatch can occur. This type of mismatch means that the cluster fails and Cisco UCS Manager cannot be initialized.

                Procedure
                  Step 1   In Cisco UCS Manager CLI, connect to fabric interconnect B and execute erase configuration.

                  All configuration on the fabric interconnect is erased.

                  Step 2   Reboot fabric interconnect B.

                  After rebooting, fabric interconnect B detects the presence of fabric interconnect A and downloads the cluster ID from fabric interconnect A. You need to configure the subordinate fabric interconnect for the cluster configuration.

                  Step 3   When the unconfigured system boots, it prompts you for the setup method to be used. Enter console to continue the initial setup using the console CLI.
                  Note    The fabric interconnect should detect the peer fabric interconnect in the cluster. If it does not, check the physical connections between the L1 and L2 ports, and verify that the peer fabric interconnect has been enabled for a cluster configuration.
                  Step 4   Enter y to add the subordinate fabric interconnect to the cluster.
                  Step 5   Enter the admin password of the peer fabric interconnect.
                  Step 6   Enter the IP address for the management port on the subordinate fabric interconnect.
                  Step 7   Review the setup summary and enter yes to save and apply the settings, or enter no to go through the Setup wizard again to change some of the settings.

                  If you choose to go through the Setup wizard again, it provides the values you previously entered, and the values appear in brackets. To accept previously entered values, press Enter.

                  Forcing a Fabric Interconnect Failover

                  This operation can only be performed in the Cisco UCS Manager CLI.

                  You must force the failover from the primary fabric interconnect.

                  Procedure
                     Command or ActionPurpose
                    Step 1 UCS-A# show cluster state 

                    Displays the state of fabric interconnects in the cluster and whether the cluser is HA ready.

                     
                    Step 2 UCS-A# connect local-mgmt 

                    Enters local management mode for the cluster.

                     
                    Step 3 UCS-A (local-mgmt) # cluster {force primary | lead {a | b}} 

                    Changes the subordinate fabric interconnect to primary using one of the following commands:

                    force

                    Forces local fabric interconnect to become the primary.

                    lead

                    Makes the specified subordinate fabric interconnect the primary.

                     

                    The following example changes fabric interconnect b from subordinate to primary:

                    UCS-A# show cluster state
Cluster Id: 0xfc436fa8b88511e0-0xa370000573cb6c04

A: UP, PRIMARY
B: UP, SUBORDINATE

HA READY
UCS-A# connect local-mgmt
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php

UCS-A(local-mgmt)# cluster lead b
UCS-A(local-mgmt)#

                    Troubleshooting Post-Upgrade IQN Issues

                    Clearing the Duplicate IQN Fault and Reconfiguring IQN Initiator Names

                    Problem—After an upgrade from Cisco UCS, Release 2.0(1) to Release 2.0(2), Cisco UCS Manager raises an IQN-related fault on one or more service profiles when you attempt to perform an action on a service profile, such as modifying the host firmware package.

                    Possible Cause—One or more iSCSI vNICS used within a single service profile or across multiple service profiles did not have a unique IQN initiator name.

                    Procedure
                      Step 1   Log into the Cisco UCS Manager CLI.
                      Step 2   Run the following command to view a list of the IQNs in the Cisco UCS domain:

                      UCS-A# show identity iqn | include iqn name

                      Step 3   In Cisco UCS PowerTool, run the script to identify the iSCSI vNICs which include the duplicate IQNs as described in Obtaining Cisco UCS PowerTool and Running the Duplicate IQN Script.
                      Step 4   In the service profile to which the IQN initiator name is not registered, change the initiator identity to the default IQN pool or manually assign a unique IQN.
                      Step 5   In the service profile in which you changed the initiator identity, change the initiator assignment to the name or pool you assigned, as follows:
                      1. UCS-A # scope org org-name

                        Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name.

                      2. UCS-A /org # scope service-profile profile-name

                        Enters service profile organization mode for the service profile.

                      3. UCS-A/org# scope vnic-iscsi iscsi_vnic_name

                        Enters the mode for the specified iSCSI vNIC.

                        Note   

                        This vNIC is not registered or visible through show identity iqn.

                      4. UCS-A /org/service-profile/vnic-iscsi* # set iscsi-identity {initiator-name initiator-name | initiator-pool-name iqn-pool-name}

                        Specifies the name of the iSCSI initiator or the name of an IQN pool from which the iSCSI initiator name will be provided. The iSCSI initiator name can be up to 223 characters.

                      5. UCS-A /org/service-profile/vnic-iscsi # commit-buffer

                        Commits the transaction to the system configuration.

                      Note   

                      Changing initiator names also involves storage side configuration, which is beyond the scope of this document.

                      Step 6   Perform an action on the service profile to register the initiator names in the Cisco UCS database.

                      For example, you can upgrade the firmware on the associated server or modify the description or label of the service profile.

                      Step 7   Run the following command to verify that the IQN changes were registered:

                      UCS-Ashow identity iqn | include iqn name

                      Reconfiguring IQN Initiator Names on a Service Profile Bound to an Updating Service Profile Template

                      Problem—After an upgrade from Cisco UCS, Release 2.0(1) to Release 2.0(2), Cisco UCS Manager raises an IQN-related fault on one or more service profiles and you cannot reconfigure the duplicate IQN initiator name on the service profile.

                      Possible Cause—The service profile that does not have a unique IQN initiator name is based on an updating service profile template.

                      Procedure
                        Step 1   Log into the Cisco UCS Manager CLI.
                        Step 2   UCS-A # scope org org-name

                        Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name.

                        Step 3   UCS-A /org # scope service-profile profile-name

                        Enters service profile organization mode for the service profile.

                        Step 4   UCS-A/org# scope vnic-iscsi iscsi_vnic1_name

                        Enters the mode for the first iSCSI vNIC assigned to the service profile.

                        Step 5   UCS-A /org/service-profile/vnic-iscsi* # set iscsi-identity {initiator-name initiator-name | initiator-pool-name iqn-pool-name}

                        Specifies the name of the iSCSI initiator or the name of an IQN pool from which the iSCSI initiator name will be provided. The iSCSI initiator name can be up to 223 characters.

                        Step 6   UCS-A /org/service-profile/vnic-iscsi* # exit

                        Exits the mode for the specified iSCSI vNIC

                        Step 7   UCS-A/org# scope vnic-iscsi iscsi_vnic2_name

                        Enters the mode for the second iSCSI vNIC assigned to the service profile.

                        Step 8   UCS-A /org/service-profile/vnic-iscsi* # set iscsi-identity {initiator-name initiator-name | initiator-pool-name iqn-pool-name}

                        Specifies the name of the iSCSI initiator or the name of an IQN pool from which the iSCSI initiator name will be provided. The iSCSI initiator name can be up to 223 characters.

                        Step 9   UCS-A /org/service-profile/vnic-iscsi # commit-buffer

                        Commits the transaction to the system configuration.

                        Step 10   In the Cisco UCS Manager GUI, unbind the service profile from the updating service profile template.