First and foremost, I understand that what I'm about to describe is not a bug, but normal behavior.
However, it caught one of our customers off guard when attempting to follow the UCS Central Operations and Best Practice Guide.
I just think the issue is interesting enough to warrant a post.
If you read about ID Range Access Control Policy feature from the UCSC best practice guide, you'll see that this is an extemely useful feature that helps to minimize the number of pools (and therefore Service Profile Templates) needed in an environment.
Although the guide only uses IP blocks as an example, the ID Range Access Control Policy can also be used in the other follow pools:
Here is a brief explanation of what the ID Range Access Control Policy feature does:
Say you have 2 UCS Domains, SitePri and SiteDR.
In UCS Central, you put them in two Domain Groups - SitePri-DG and SiteDR-DG, respectively. (You do use Domain Groups, right?)
Now, say you want SPs (Service Profiles) deployed inside these two Domain Groups to use different IP ranges, UUID ranges, MAC ranges and WWXN ranges. For example, you want it like this:
| Pool Type | SitePri SPs to use: | SiteDR SPs to use: |
|---|
| IP | 192.168.0.0/24 | 172.16.0.0/24 |
| UUID | 00FF-000000000001 x500
| 00FF-100000000001 x500
|
| MAC | 00:25:B5:00:00:00 x500
| 00:25:B5:10:00:00 to x500
|
| WWNN | 20:00:00:25:B5:00:00:00 x500
| 20:00:00:25:B5:10:00:00 x500 |
| WWPN | 20:00:00:25:B5:00:00:00 x500
| 20:00:00:25:B5:10:00:00 x500 |
Now, without using the ID Range Access Control Policy feature, you'd have to create two sets of the pool, and then two SP-Templates. E.g., TemplatePri points to IP-Pool-Pri, UUID-Pool-Pri, MAC-Pool-Pri, WWNN-Pool-Pri, WWPN-Pool-Pri.
TemplateDR points to IP-Pool-DR, UUID-Pool-DR, MAC-Pool-DR, WWNN-Pool-DR, WWPN-Pool-DR.
The ID Range Access Control Policy helps to make the above much more efficient by allowing you to add multiple blocks of - say WWNN - in a single WWNN pool, with each block associating with a Domain Group.
The effect is that you only need to create one WWNN pool, and therefore you only need to create a single SP-Template that points to this WWNN pool. (I'm using the WWNN pool in this example, but you can do this to all those other pools too).
When you create a SP from this SP-Template and associate it with a blade located in SitePri-DG, the SP will pick a WWNN from the WWNN pool. It will see two blocks of WWNNs, and it will pick the block that is associated with the SitePri-DG Domain Group. Same thing happens when you create a SP from this same SP-Template and associate it with a blade located in the other domain in SiteDR-DG, only this time, it will pick a WWNN from the block that is associated with the SiteDR-DG Domain Group.
As you can see, you saved yourself from having to create a whole different set of pools and SP-Template.
What's the problem, then?
The problem:
For those that do not currently use the ID Range Access Control Policy inside their pools (Again I will use the WWNN pool in this example), each WWNN block in the pool will not be associated to any Domain Groups.
The effect is that, as soon as you create a SP from the SP-Template that uses this WWNN pool, a WWNN from the pool will be assigned to the SP even without the SP being associated to a blade that belongs to a Domain Goup.
This is understandable because the decision to pick a WWNN from one of the blocks in the pool is no longer dependant on which Domain Group the SP may end up associated to.
In comparison, when using the ID Range Access Control Policy method, a WWNN will not be assigned to the SP the moment the SP is created from the SP-Template, but only when the SP is finally assigned to a blade inside a Domain Group.
This is also understandable because the decision to pick a WWNN from one of the blocks in the pool is, this time, entirely dependant on which Domain Group the SP ends up associated to.
But, this is not actually the problem. The following is the problem.
When using the ID Range Access Control Policy method, as soon as you unassign a SP from a blade (and therefore, a Domain Group), the WWNN (and of course, IP, UUID, MAC, WWPN too) will be released back to the WWNN pool. This can be a problem to some people.
When you use the ID Range Access Control Policy method, again, the WWNN block used to pick a WWNN from will be dependant to which Domain Group a SP is currently associated to. So logically, it makes sense that the WWNN will be released when the SP is no longer associated to a Domain Group.
If you don't use the ID Range Access Control Policy, the WWNN will contine to stay assigned to the SP even if the SP is no longer associated to a Domain Group, because the WWNN was never dependant on a Domain Group in the first place.
Why is this a problem for some people?
This may sound strange to some, but some people create more SPs than the number of physical blades they have, and they swap them around as needed. E.g., Associate SP1 to Blade1 today. Tomorrow, swap out SP1 with SP2 on Blade1, etc.
In this example, they have no intention to release SP1's currently assigned IPs, UUID, MAC, WWXN back to the pools. In fact, they want SP1 to keep a hold on them! Because they will eventually reuse SP1 again.
And if you use boot-from-SAN, this is even more important because you do not want your vHBA WWPNs to change at all.
But, alas, with the ID Range Access Control Policy method, as soon as a SP is unassociated from a blade, all those resources will be freed back to the pools they came from. In this case, their practice to swap SPs around and later reuse will no longer be possible, as least not easily.
PS: Thinly veiled help request: If you know of a workaround, please share it. Thanks!
