No there would be no production impact. You would still be able to access your nodes imms through the CMM as long as the CMM can still see them. All internal management communication goes through the CMM that includes switches as well as imms. Unmanaging the chassis from the FSM will only disable any management activities from the FSM alone while the chassis is unmanaged.

My best suggestion is to upgrade all of your compute node firmware using Bootable Media Creator. Once upgraded, verify your CMM is the latest. Then from the FSM 'unmanage' the chassis and then follow the command line method for upgrading your firmware to the latest version. Once the upgrade is successful try to remanage the chassis.

Good afternoon, thank you for your post. I would advise trying to make sure you can upgrade the fsm. Try to remove all updates from the FSM database by running 'smcli cleanupd - mva' and then reboot. Also make sure the fsm version you are trying to upgrade to is a compatible upgrade path from your current version. If the problem persists please reply with a screenshot if the error.

Good morning, thanks for the question. No unfortunately we never got a solid answer on what this was happening. We believe it was a hardware/firmware issue with the Emulex adapter but neither IBM or VMware took credit for being the root cause of the problem. We began to ignore the issue since we know those VMnics are down.

From the document:"Trunk groups are also useful for connecting a SI4093 to IBM switches andthird-party devices that support link aggregation, such as Cisco routers andswitches with EtherChannel technology (not ISL trunking technology) and Sun'sQuad Fast Ethernet Adapter."

Since this switches are essentially passthrough switches where you create a SPAR (which is essentially a logical configuration combined INT or internal ports to EXT or external ports) there does not appear to be a way to "stack" these switches since they have little to no intelligence built in. If you would like to stack the switches that would require the EN4093 switch which has an almost identical command set and functionality set to Cisco when you configure it to use the ISCLI (Industry Standard Command Line Interface).

Keep in mind also that the SI4093 can be tricky to configure although the marketing material would tell you otherwise. I have seen this switch deployed at only one customer, the rest have had the EN4093. I do not want to deter you from your solution but simply warn you that it may not be as easy as it seems. There are a few posts on issues that have been seen here in the MyPureSupport community so if you do hit a snag do a search and see if you find some answers, otherwise post again.

Interesting. So its hanging on the RHEL login instead of automatically booting into the FSM software. Since you already rebuilt it 2 or 3 times I don't want to suggest doing this again but it does sound like there may have been an issue when the recovery rebuild the Recovery Partition. Did you try to download the newest recovery media? It should be 1.3.4.

I've had issues in the past rebuilding from scratch but never associated to the F12 Recovery Partition, it was always due to the USB CD-ROM device I was using. If you got past those steps successfully and are sure your RAID arrays are set to 'Boot' and the HDD is set to 'ALT' then I'm not sure what it could be short of corrupted installation media.

Is there an MD5 checksum file you received with the recovery media that you can check to make sure that the downloaded media has the same MD5 sum as the file from IBM?

If you want multiple VLANs to pass to the chassis then, yes, you would need to configure EXTA1 as a trunk port. You could leave INTA1 at VLAN 1 but if you want that server to only have access to the production VLAN of 116 then INTA1 would need to have 'switchport access vlan 116' defined.

In order to assist please provide the output of the command 'show logging' (in ISCLI mode).

Also, have you seen this article on MPS? It looks like you may have a similar issue where an LACP trunk group may have failover enabled where if all links in the trunk are not active it will set the internal ports to disabled.