Under each VSAN in Domain Manager it shows that persistent FCIDs have been Enabled. Assignment is dynamic and in the Used column it shows that
some of the devices are True and others false. I didn't set this up and know a bit about Windows servers using persistent bindings but what does this mean? Is it something I should worry about as I have True and False and as I have only Windows boxes do I need it?
I remember reading about AIX servers needing persistent FCIDs, is it to do with that?
If you only have windows boxes, no you dont need to worry about it.
Some host O/S's use the target ports FCID as a way of referencing the storage, so if the FCID changes (switch reboot) they loose the disk and can't get the original luns back. They tend to see "new" luns
Windows does not use FCID's.
You were nearly right with AIX. For the past few years you have been able to turn on a feature called dynmic tracking which tolerates FCID changes. Hving said that, there are ALOT of AIX hosts about with this feature disabled.
It states in some of the Cisco documents that FL devices might have issues with Persistent FCID's. We have our Tape Library on the switches and the Robot is FL, will that cause a problem when moved? See below.
Note Persistent FC IDs with loop-attached devices (FL ports) need to remain connected to the same port in which they were configured.
HP-UX also has the need for the target FCID to remain the same. If the target FCID changes, like AIX, you would need to run IOscan to rebuild the lun binding in the operating system to account for the new FCID. Since SAN OS 2.x the FCID mapping has been persistent meaning if a device logs back into the same VSAN on the same swtich, the swtich will attempt to provide it with the same FCID as it was originally allocated at the first login. As was pointed out, Windows, Linux and Solaris have no issues with a change in the target FCID. HP-UX and most AIX implemtations would require an IOscan if the target FCID changes.
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...