Posts Tagged ‘Cisco’

UCS: Renaming service profile in Cisco UCS 2.1


13 Jun

Starting from UCS version 2.1 there is an option to rename service-profiles and templates in UCS. If you’re running 2.0 or lower then the only way to rename is to clone service profile make some changes and delete the original, you can read about this here.

Rename service profile in UCSM GUI

  1. Start UCSM and select Servers tab.
  2. Change filter to Service Profiles or All so that service profiles are visible
  3. Right click on the service profile you want to rename ans choose Rename Service Profile
    spr1
  4. Enter new name and click OK
    spr2
  5. You’ll get a dialog box that the profile was renamed. Click OK
    spr3

Rename service profile in CLI

  1. Use SSH client to connect to UCS CLI
  2. You have to know where the service profile you want to rename is located. In my case it is in the root. Type:
    scope org /
    ‘/’ is a location of service profile. If it is in sub-organization then you have to provide then name for it
  3. To select service profile type:
    scope service-profile name
    ‘name’ is a name of the service profile you selecting
  4. to rename type:
    rename-to newname
    ‘newname’ is the name you renaming profile to
  5. you will be asked to confirm. Type ‘yes’
  6. to commit changes type
    commit-buffer
    spr4

UCS: How to move or rename service profile in Cisco UCS


13 Jun

So UCS version 2.1 has added feature to rename service profile but what to do if you are running 2.0 or if you need to move service profile to different sub-organization?
Here are the steps you need to perform.
Before performing rename/move you’ll need to schedule maintenance window as during the procedure the blade will go down.

  1. Open UCSM GUI and select Servers tab
  2. Change Filter to Service Profiles or All so that service profiles are visible
    From this point all actions are performed on the original service profile(the one you want to rename/move)
  3. Right click on the service profile you want to rename/move and select Create a Clone
    1
  4. Enter the new name that you want to rename service profile to or if you are moving then enter the same name and change organization. Click OK. A clone should be created.
    2

(more…)

Nexus: Upgrading Cisco Nexus 5000


06 Mar

So here is how to upgrade Nexus 5000 series switch. In this instance I have 2 Nexus 5010 switches in vPC configuration as they are part of the Vblock. I will be upgrading them from 5.1(3)N1(1a) to 5.2(1)N1(1)
First of all, although upgrade procedure is pretty much the same, please always check with Cisco for latest upgrade guides:
http://www.cisco.com/en/US/products/ps9670/prod_installation_guides_list.html

For the upgrade to be done as quick as possible it is important to do some work before it, like downloading the files from Cisco, uploading them to switches and running checks.

  1. Download Kickstart and System files from Cisco.com
  2. Verify that you have enough space on the switch
    dir bootflash:
    030613_2025_NexusUpgrad1.png
  3. Upload both files to the switch. In this case I used TFTP server:
    copy tftp://x.x.x.x/kickstart_or_system.bin bootflash:            <=== replace x.x.x.x with TFTP server IP, kickstart_or_system.bin with your Kickstart or System file name.
    type management when asked to Enter vrf
    030613_2025_NexusUpgrad2.png
    Note: In Vblock upload files to both switches. Copy operation might take some time.
  4. Once both Kickstart and System files are uploaded verify that the file size of both files is correct.
    dir bootflash:
    030613_2025_NexusUpgrad3.png
  5. Now we need to run some pre upgrade checks which will show if there any problem that should be fixed before the upgrade can be started
    show compatibility system bootflash:system.bin            <=== replace system.bin with your System file name.
    You should get No incompatible configurations message
    030613_2025_NexusUpgrad4.png
  6. Next we to see the impact of the upgrade:
    show install all impact kickstart kickstart.bin system system.bin        <=== replace kickstart.bin and system.bin with your Kickstart and System file names.
    This procedure might look like a real upgrade but it only does all the checking
    030613_2025_NexusUpgrad5.png
    It will take some time to complete. It must succeed at all steps and should show that upgrade is non-disruptive
    030613_2025_NexusUpgrad6.png
  7. Now check spanning-tree impact. Everything should pass
    show spanning-tree issu-impact
    030613_2025_NexusUpgrad7.png
  8. Check lacp impact
    show lacp issue-impact
    030613_2025_NexusUpgrad8.png
  9. There is also show fex to verify that all fabric extenders are reachable but in the Vblock there are no extenders connected to the switches so this can be skipped.
  10. Once steps 1 – 9 are completed and all are OK you can proceed to upgrade.
  11. Because this is Vblock and 2 switches are in vPC config you need to identify the primary one as the upgrade should be started from primary
    show vpc role
    030613_2025_NexusUpgrad9.png
  12. Start upgrade
    install all kickstart kickstart.bin system system.bin        <=== replace kickstart.bin and system.bin with your Kickstart and System file names.
    030613_2025_NexusUpgrad10.png
  13. Once prompted verify to continue by pressing y
    030613_2025_NexusUpgrad11.png
  14. The upgrade will begin.
    If you connected to switch remotely over SSH, you will lose connectivity after seeing Saving supervisor runtime state
    message as the switch is rebooting. This should take about 5 minutes. Ping it to find out when it is back online.
    030613_2025_NexusUpgrad12.png
  15. Login to the switch and check upgrade status. If upgrade went ok you should see that it was successful.
    show install all status
    030613_2025_NexusUpgrad13.png
  16. Verify version
    show version
    030613_2025_NexusUpgrad14.png
  17. Verify that everything is working as expected.
    Upgrade is complete
  18. In Vblock once you’ve verified that primary switch is working fine, upgrade the secondary switch.

UCS: F0382 thermal-problem


06 Feb

This is a quick post for simple error that you might see in Cisco UCSM.
t1
Affected object: sys/chassis-2/fan-module-1-2
Description: Fan module 1-2 in chassis 2 temperature: upper-critical
Cause: thermal-problem
Code: F0382

This may indicate that there is hardware problem with the fan and it needs to be replaced but quite often it indicates logical problem. There are a few bugs depending on the version that UCS is running that might cause this behaviour.
As we can see from the error the problem is with the fan in chassis 2.
If you click on the blue text it will open a new window and you’ll be able to see which fan it is.
t2

The first thing you can try is to reseat the fan and see if the error goes away. If it does not then it most likely hardware issue.
In this case the error has cleared.
This error might reappear in couple day/weeks or months or it could happen on the other fan. There is a known I2C bug in UCS. To clear i2c bus it is advised to reseat all fans, PSUs and IOmodules(one at a time).
The bug was fixed in late 1.4(3*) version but was reintroduced again in 2.0 version. It should be fixed in latest version.
I UCS system affected by this bug than you still need to reseat components as the upgrade alone will not clear the I2C bus.
IMO it would be best to reseat them before upgrading as at least you’ll be upgrading a healthy system.

UCS: FSM: Unable to find Storage Controller Device for sys/chassis-4/blade-2/board/storage-SAS-1 to perform Image update


30 Jan

Here is a strange error that popped up recently.
After server reboot the blade got stuck on 47% of associating service profile.
Here is the error:

Remote Result: Service Unavailable
Remote Error Code: 4106
Remote Error Description: Unable to find Storage Controller Device for sys/chassis-4/blade-2/storage-SAS-1 to perform Image update

1

 

When looking in the KVM Console for the blade I can see that it was sitting in the screen below:
2

Here are the things that I’ve tried to fix this and none of these worked:
1. As it was saying about the image update for Storage adapter I though I’ll remove Host firmware policy from the service profile.
2. Next I created a new Host firmware policy but only added firmware SAS storage controller and chose different version than it had.
3. Remove and add service profile back

Here is what worked though:
Removed service profile from blade, re-acknowledged the blade added service profile back. After this the error was gone and the blade was booting normally.
The last step was to add old Hast firmware policy to the service profile and check if that brakes it again, but all worked as expected.
So I’m happy that the blade is back but cannot explain how and why this has happened.

UCS: F999616 [FSM:FAILED] communication service configuration(FSM:sam:dme:CommSvcEpUpdateSvcEp)


12 Jan

In UCSM you see critical error:
Affected object: sys/svc-ext
Description: [FSM:FAILED] communication service configuration(FSM:sam:dme:CommSvcEpUpdateSvcEp)
Cause: fsm-failed
Code: F999616

ntp

The error itself is not very descriptive, so in order to find out what the problem is best it to look at UCSM show-tech support logs.To do that select Admin tab, select All and click on Create and Download Tech support.

ntp1
(more…)

I’m now CCNA Data Center


11 Jan

This week I’ve passed 640-911 and 640-916 and now holding CCNA Data Center certification.
Next is CCNP Data Center 🙂

UCS: flashing cursor after installing Linux (RedHat, Suse), server would not boot


04 Jan

Here is an interesting thing that happens during Linux installation on Cisco UCS blade.
After installing Suse on Cisco UCS blade, the server would not boot and only flashing cursor is seen. Tried other version of Suse and even RHEL, still the same. This looked strange because I had installed Linux on UCS without any problems before.
There is a small thing that you need to be aware when doing installation. Make sure to add CD-rom in boot order in the the service profile and after you mount your ISO let the sever to pick it up itself. Do not press F6 and choose for it as this is where interesting thing happens.
When you let the server to pick the boot device it makes Linux installer to think that this server is running in UEFI mode.
When you press F6 and choose the boot device the installer thinks it is BIOS mode and when partitions are created, it messes things up there for after reboot you see flashing cursor.

UCS: Warning: there are pending SEEPROM errors on one or more devices, failover may not complete


03 Dec

In UCS CLI after issuing command ‘show cluster state‘ a warning is received on one of the chassis.

UCS-B # show cluster state
Cluster Id: 0xf122a7f83dba11e0-0x9a4c123573c4f1c4

B: UP, PRIMARY
A: UP, SUBORDINATE

HA READY
Detailed state of the device selected for HA storage:
Chassis 1, serial: FOX1234567A, state: active
Chassis 2, serial: FOX1234567B, state: active
Chassis 5, serial: FOX1234567C, state: active with errors

Fabric B, chassis-seeprom local IO failure:
FOX1234567C READ_FAILED, error: TIMEOUT, error code: 10, error count: 7
Warning: there are pending SEEPROM errors on one or more devices, failover may not complete

In sam_techsupportinfo  log you’ll see the following message
Creation Time: 2012-10-12T01:12:21.217
ID: 2712562
Description: device FOX1234567C, error accessing shared-storage
Affected Object: sys/mgmt-entity-B
Trigger: Oper
User: internal
Cause: Device Shared Storage Io Error
Code: E4196537

This is known Cisco Bug CSCtu17144 and here is what needs to be done

If the fault condition stays on or keeps being cleared and re-raised, try the following workarounds:
1. Reboot the IO module.
2. Remove and re-seat the IO module. Make sure the module is in contact with the backplane firmly.

I’ve had this problem couple times and resetting IO module was enough in both cases

UCS: configuration-failed; Code: F0170; connection-placement; There are not enough resources overall


02 Dec

Here is an interesting issue that I ran into with Cisco UCS blade.
I needed to move service profile from one blade to another. This is a process that should not give any problems but it did. Dissociation worked fine, but when I tried to associate the same profile with diferent blade I ran into problems.

The first thing I noticed is Config Failure error in Status:

The Configuration error was:
connection-placement
There are not enough resources overall

Not enough vHBAs available
Not enough cNICs available (more…)

IT Blog

Just another blog on Kozeniauskas.com Network