cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
223
Views
0
Helpful
1
Replies

Disassociate server causes server to re-associate to a different SP

JDMils
Level 1
Level 1

A very strange thing just happened which has never happened before. I needed to change the vNIC Template on a Service Profile Template (SPT) which has 4 associated SPs with only 2 SPs associated to physical servers. Changing the firmware policy on the SPT caused the SPs to go into a Config Failure. Reason was that the original vNIC Templates which were connected to the SPT had been deleted and the SPT was running on a "ghost" image of the original vNIC Templates. I thus had to rebuild the SPT vNICs and create new vNIC Templates to associate to the SPT vNICs.

SPT name: SPT_Template01
Bound SPs:
SP_SP01 (not associated)
SP_SP02 (not associated)
SP_SP03 associated to chassis 17 blade 7- ESXi host
SP_SP04 associated to chassis 17 blade 8- ESXi host

I thus unbound SP_SP04 so that any changes to the SPT would not affect the running server associated to SP_SP04. I need to keep this running for now.

I then edited the vNIC Templates attached to this SPT and modified the vNICs of the SPT to use the vNIC Templates (something happened to the original vNIC Templates- they must have been deleted so the SPT now had a "ghost" image of them).

This change of course caused SP_SP03 to reboot which is fine- the ESXi host was in maintenance. This host is now working OK and the firmware on the blade updated with the reboot.

I then powered down SP_SP04 as the physical host was in vSphere maintenance. I disassociated the physical server from SP_SP04 and renamed SP_SP04 to SP_SP04_OLD.

I created a new SP from the SPT and called it SP_SP04 and tried to associate it to the physical server in Chassis 17 Blade 8. I got an error that stated this was not possible as the blade was already associated.

Checking the physical blade association, it was associated to SP_SP01. I disassociated it from SP_SP01, it went thru the motions, monitoring the FSM until it got to 100%, I then checked the physical server and it was now associated to SP_SP02. I tried the same disassociation and the blade associated itself to SP_SP01 again and the same happened when I tried it again.

Using "Change Service Profile Association" on SP_SP01 & SP_SP02, I set them to the pool "B200M3" coz I have no M3s in the environment hoping this would deter the blade from associating itself to the SPs, but it still did.

The only think which fixed this was to delete all unused SPs and leave my intended SP_SP04 as the sole SP in the Org, and finally the blade associated to this SP.

However, I tend to remember all the SPs in this Org being associated to the wrong physical servers and asked my IAAS team to fix this. Now I know why! But not how.

So how and why is the blade automatically associating itself to any SPs it finds in this Org?

Infrastructure firmware: 4.2(2c) [We have M4s in the environment]
Blade firmware: 4.1(1d)
FIs: 6296
Blades: B200M5

1 Reply 1

Kirk J
Cisco Employee
Cisco Employee

Sounds like you have server 'pools' setup which can cause this kind of behavior your have described.

I would disable the pools, or at least remove the physical servers from being associated with the pools.

Kirk...

Review Cisco Networking for a $25 gift card

Review Cisco Networking for a $25 gift card