- Integrated Systems
- About Us
- Integrated Systems
- About Us
04-02-2012 05:58 PM
VC Configuraton, Swap VC 4GB FC Modules for VC 8GB 24-Port Modules
Joe had an upgrade question:
A customer needs to switch to 8GB 24-Port modules. The VC configuration was performed in November. The solution is live and the desire is to prevent zoning changes. Work will be done over a weekend, hopefully less than a half day. The Network, i.e. VC Flex-10 Modules in will not be disturbed.
My plan is to:
1) Take a backup and run against the backup generator and preserve the WWNs.
2) Delete the DOMAIN.
3) Swap the Modules
4) Either cut and paste sections of the output of the backup generator or start the wizard and import the domain.
5) Based on step 4 cut and paste remaining lines to get the Uplink information, the Network information and the Profile information.
6) By preserving the WWNs with the generator, the issue with zoning will be avoided.
7) Test and verify, then completed
In the VC CLI User Manual, it suggest delete the Profile(s) and make the swap but that will force new WWNs to be picked up, not desirable.
I am looking for comment.
Why would you need to delete the domain?
Why not just remove all up links from the existing fabric definitions, swap the modules and then re-assign up links to new 24 port modules?
WWN is either stored in the HBA or Profile and swapping the modules shouldn't wipe any of that.
Unless I'm totally missing something and swapping/removing modules is unsupported
When the VC domain was originally created, it imported 20-port VC modules. I think if you just added 24-port modules in empty slots, you might be able to just add to the original domain. But since you are changing the type of VC module in the same slots, I do think you will have to delete the domain and create a new domain and import the different modules.
What do you mean when you say you will use "the backup generator" and be able to preserve the original WWN's?
If you Know exactly what the original WW names were, Can you create a new server profile with "user-defined" WWN's and input the original WWN's?
And from Alex:
Please refer to the "Upgrading to an HP Virtual Connect 8Gb 24-Port FC Module" section of the HP Virtual Connect for c-Class BladeSystem Setup and Installation Guide on page 45 and follow these steps:
Replacing an HP 4Gb VC-FC Module, HP VC 4Gb FC Module, or HP 8Gb 20-Port FC Module with an HP VC 8Gb 24-Port FC Module
1. Upgrade the VC domain firmware to v2.10 or higher.
2. Verify that the replacement will result in a good configuration. See "Multiple enclosure guidelines (on page 20)."
3. Verify that the user has Server privileges.
4. Remove any FC profile connections that are connected to the interconnect bays being upgraded. To remove the profile connections, un-assign the profile, and then delete the connections from the profile.
5. If any FC SAN fabrics were created using uplinks from the interconnect bays that are being upgraded, delete these FC SAN fabrics from the Virtual Connect domain.
6. Physically remove the existing modules from BOTH horizontally adjacent bays for each enclosure in the domain. In a double-dense domain, remove the modules from Bay 7 and Bay 8 when removing modules in Bay 5 and Bay 6.
7. Ensure that the VC-FC modules are no longer shown in the domain.
8. Install the HP VC 8Gb 24-Port FC Modules.
9. Re-create previously deleted FC SAN fabrics.
10. Re-assign the server profiles, and then add the FC connections to the profiles.
It is true that you can simply delete domain and swap modules. you won’t be able to recover binary config file since module types are different and it won’t’ necessarily preserve WWN assignments.
Secondly, when MACs and WWNs are manually specified in the “add xxx-connection” commands, they are no longer considered VC-managed attributes, but rather externally-managed. What this means is that when a profile is assigned with these MACs/WWNs, they will be removed from the MAC/WWN pool, but if the profile is ever deleted, they will not be returned to the MAC/WWN pool because VCM assumes that the profile still could exist on another enclosure or another domain and would want to avoid duplication, so essentially you are creating holes in the pools of MACs and WWNs by manually assigning these attributes.
Any Questions or comments?