Need advice with FCS Raid Manager Disk settings

Hello friends, recently I was suppose to replace the hard disk on my Primergy RX server, on the serverview Raid manager it showed that the other disks in the RAID were set to “NO” where as the foreign configuration was set to YES, but however it did work. There are also certain things which confuse me a lot but also on the other hand they seem to be correct.

As I have never tried out this procedure ever before I just wanted to get an assurance for anyone over here that the drive and the operating system and application or any other software will always remain unaffected and will not render the disk as reformatted or deleted after initiating this procedure. I know that rebuilding a server and set it back to its original position has always been a problem. So is there anyone who can suggest me or advice me with the operation I need to take place.

Yes definitely I will really help you out with this thing, if you check out in the manual it has been clearly shown the procedure for “manage foreign configuration” and also mentioned or stated to select “Clear” in order to remove any of the foreign configuration from the RAID array in the server and then later on it would ask for the confirmation with only YES that is typed in the block. The foreign config always come up with the conclusion of the RAID configuration that is being held on any disk in the array or the controller in NVRAM.
Each and every connection disk has a COD i.e. configuration on Disk, which however at the starting of the disk takes up small areas.

Once removing the Fujitsu disk and then replacing it with a Seagate HDD somehow works fine and well and the array however without any error message resynchronize. It has been said by the MegaRAID that the "Foreign Configuration" and also the following requirements are needed to be done to adopt the prodigal disk:

• Right-click on the disk and "Make ready"
• Remove the disk again
• Replace the disk back again
• The array will resynchronize now

It’s that when the controller is booting it actually reads the NVRAM configuration and along with that also reads the COD from all the disks connected to it. The foreign config is anyhow reported if there’s any inconsistency encountered. The main idea behind this is that once the controller is failed and if its replaced the configuration can somehow be restored from the COD without even reconfiguring the RAID controller and array.

In the same way also if the disk is failed and if its replaced with the completely new and a fresh disk, the new one will be surely imported into the array along with the complete information from other CODs.

Quote:

---

Its that when the controller is booting it actually reads the NVRAM configuration and along with that also reads the COD from all the disks connected to it. The foreign config is anyhow reported if there’s any inconsistency encountered. The main idea behind this is that once the controller is failed and if it’s replaced the configuration can somehow be restored from the COD without even reconfiguring the RAID controller and array.

---

What according to me wrong is your new disk, because I think you new disk is not really a cleaned one, just let me know did you ever used it from any other server. Just because of that I feel that the COD on the disk is from a previous life only when the controller detects the new disk. It however spots that the COD is not at all matching everything and also the flags up.

In my case, it is nicely able to clear the foreign config on the new disk but what you are doing is erasing the COD on the disk and managing to somehow make it available as a replacement disk due to which the array is rebuilding onto the new disk. The new disk that you insert is proper but just because of the foreign config you can see it currently being unused until and unless the complete conflict is resolved and the volume will remain in the degrader.