I use updating service templates to ensure all service profiles are the same and it works great. We have recently setup a Nimble storage array and for iSCSI boot you have to put the target of of the boot LUN in the iSCSI boot parameters. However as each profile will have to boot from a different volume. This causes an issue as I cant change a service profile that is bound to a service template and i need the profiles to have differnt boot volumes.
I am not sure if your Nimble array works differently from other arrays, but with other arrays you can group different initiators IQNs with different boot LUNs, it doesn’t matter if they are pointing to the same target IQN. There is nothing wrong with UCS, what you have to do is to group your boot luns to their corresponding initiator IQNs. If you really want each server to point to a dedicated iSCSI target, you will have to unbind the service profile from the template and create a new boot policy for each of your server. At this point you will lose the ability to update your service profiles from your template.
Note each service profile get a different initiator ip address and a different initiator IQN
Sorry I am not following. I know each profile gets a IQN but you have to add in a target for the server to boot from and this will be differnt each time. If this added to a service template it then can't be updated.
The service profile requires two different IQNs one for the initiator/server and one for the target/storage_array. What I’m saying is that each initiator needs to have a different IQN but all of them can use the same target IQN to communicate to the storage.
If you are using an updating template to update all of the service profiles, any change you make there will be propagated to all of the service profiles that were created from this template, which means that you can only make changes to the template and not directly to the service profiles unless you unbind them from this template.
The main thing you need to understand is that if you use the same target IQN it doesn’t mean that all of your server are going to try to boot to the same LUN as long as you group their IQN (initiator) to a dedicated LUN on the storage array.
After doing some testing and looking at the nimble guide you have to put the IQN of the LUN in the boot parameters. There is no generic target IQN which you can then sort by initiator groups. This prohibitives the use of updating templates.
For FC it is different as the template holds the WWN of the SP and then LUN masking controls access to LUNS.
The problem is that the Nimble does work differently from other arrays. It uses a unique target for each volume/lun presented to the host so all LUNs are essentially LUN 0 with a extended unique identifier (EUI) to denote each volume. Unless Cisco decides to decouple the boot policy from the Service Profile Template or allow for a target override on each Service Profile instance, initial templates are the only practical implementation for a SmartStack with iSCSI boot at this time.
VMware Trunk Port Group is supported from ACI version 2.1
VMM integration must be configured properly
ASA device package must be uploaded to APIC
ASAv version must be compatible with ACI and device package version
In the Previous articles of ACI Automation, we are using Postman/Newman as the Rest API tool to automate the ACI Configuration.
In this article I’m going to discuss on usin...
One of the first steps in building your ACI Fabric is to go through Fabric Discovery. While Fabric Discovery is usually a straightforward process, there are various issues that may prevent you from discovering an ACI switch. This article wil...