Just want to use the following as a troubleshooting example for service profile association. Here is a very common problem in the service profile configuration lab in the DCUCI course. (Most likely because the lab instruction is not very clear).
The profile fail to associate with a blade server. In the general tab of the service profile, it shows the configuration error as the following screen:

To troubleshoot, first of course need to pay attention to the error message, in this example is the QoS policy which cannot be applied. To double check, click the Faults tab to review the recent logs.

Now you confirm that it is the QoS policy problem. Then what’s next, where is the QoS being applied? One of the places being focus should be the virtual NIC, so go to the vNIC of the profile (using the Navigation pane). On the General page, though there is a warning, the QoS policy is actually applied. (Same as the 2nd vNIC).

Then what other place will have the QoS policy? Right, it is the vHBA.
So navigate to the vHBA, and finding that the state is “line rate is failed to apply”.

Click on the Faults tab to double check that the vHBA failed to apply configuration.
Actually the QoS policy being applied is for the vNIC, the traffic class is not marked as FC which can not be applied to the vHBA.

In fact, in this lab, we don’t even need to apply the QoS policy. So the simple solution is to just take out the QoS policy. Yet, from the Warning message, we know that the service profile is associated with the template. Thus we need to change the template instead of the service profile directly. Now, navigate to the vHBA of the corresponding template. Again we find that the vHBA is associated with a SAN template.

Thus, finally we need to go to the SAN template, unselect the QoS policy.

Back to the service policy, see! Its now starting to associate,

Can monitor the console by using the KVM.

In last week when I delivered the DCUCI class, one of the questions from student is: can a blade server be used immediately after plug into the chassis – strictly speaking it means can a service profile automatically be assigned to a newly plug in physical server.
The answer is yes. Actually we can pre-provision service profile i.e. a server profile assigned to an empty pool (or a pool that without any more unassigned server). Then using the pool autopopulating configuration (Create a server pool qualification by specific e.g. CPU, memory requirements. Then create a server pool policy by placing the server pool qualification and the target pool), once the new server is plugged in (and if it satisfy the pool qualification requirements), it will be automatically populated to the pool and the service profile will be immediately assigned to this new server.
Following figures illustrate the procedure.

1. Create a service profile and assigned to an empty pool. Here shows the service profile and the pool:

Note that the profile is in unassociated state and server assignment is failed (that’s normal at this stage).

2. Now I manually move a server to the pool (you can also use autopopulation for physically add a new server)

3. Then back to the service profile, now you can see that the service profile immediately assigned to the new server without any human intervention.

 

Just finish the FlexPod training, there are 2 things that want to clarify.

The fist thing is about the FCoE connectivity between the Nexus 5K and the Netapp storage. The reference architecture (diagram below) shows that a vPC is formed between the 2 N5K, then the vPC connects to the ifgrp of the Netapp filer.

Here there is an important points to be aware. The vPC can be used to carry traffics for all data VLANs, but not the FCoE traffic. In fact, in the design guide, it mentions that in order to key the SAN A/B design (as from the UCS SAN traffic design, we always keep 2 different storage paths). the FCoE traffic of a particular VSAN (which actuatlly caried by VLAN) will not be send in both links of the vPC. E.g. if the left hand side N5K is carrying the traffic of VSAN 201 over VLAN 101, while the right hand side VSAN 202 over VLAN 102 Then the links from the left hand side N5K to the Netapp will only carry VSAN 201/VLAN 101, while right hand side is VSAN 202/VLAN 102.

While data VLAN will have no restriction, e.g. if VLAN 50 is for data, then the VLAN 50 traffic can be carried over all 4 links (as below).

The 2nd thing is, currrently the FCoE cannot support FCoE port channel, i.e. you can't use 2 parallel links connecting the Netapp filer to the same N5K. Thus for FCoE storage deployment, the reference design is the only valid physical connectivity design.

Just finish teaching the Cisco UCS (DCUCI) course this week, I find that there is a small bug about the Unified port configuration and want to share in this blog entry.
As in the lab, it requires to configure last few ports of the Fabric Interconnect as FC uplink ports, while we are using the 6248 Fabric Interconnect, which by default the ports are unified ports, so need to first configure them as the FC ports.
The ports to be configured are all the ports in the expansion slot. By using the UCSM, select the corresponding Fabric Interconnect, and click the Configured Unified Ports:




In the popup window, select the Configure Expansion Module Ports: 

Drag the slide bar, so that the right hand side ports will become FC ports. Then click Finish.

What happen is that you would expect that those configured ports should be appeared under the Uplink FC port, however nothing is found there!

 So how can you fix it, you need to Disable All Ports:

 Then re-enable all the ports again:

Now all the FC uplink ports appear:

- Kepler (Cisco Certified System Instructor #20388, since 1998)