Updating SCOS on Dell CT-SCV2080

I am in the process of decommissioning an older Dell SCV2080 and I thought it might be a good opportunity to try to update the Storage Center Operating System (SCOS) as the unit is being decommissioned.

When I had this unit in production, its function was mainly to retain backups. As it has aged, support expired and getting replacement drives started to become a challenge. The drives are firmware locked by Dell and purchasing drives online was always a gamble for compatibility reasons. In 2023, I replaced this unit with a new Dell PowerVault ME5084 so I figured that now is a good opportunity to play around with this SCV2080.

When it was used in production and without any support, I couldn’t risk doing these software updates as I had no guidance from Dell or access to the files. The SCOS software used in this article was from the SCV2020 unit that I was able to obtain when troubleshooting with Dell on a previous active ticket. As both storage arrays are part of the SCV2000 series, I wanted to try to update the SCOS on this unit and see if it would take.

Files:

https://mega.nz/file/4NBhFSRD#ACr-GiZkPxfAmGNurTVDNrW3NpFuiNWl33BfI19Smh8

The SCV2080 in question has 171TB of raw space across 47 4TB disk (3.64TB recognized). The operating system is an older SCOS version of 7.1.12.2. To manage this storage center, I have had to use an older version of Dell Storage Manager (DSM) (2018 R1.10, build 18.1.10.171).

Since I’ve replaced this unit with a much newer and larger SAN and this one is being decommissioned, I wanted to try to update the SCV2080 using my guide found below:

https://tweakmyskills.com/dell-compellent-storage-center-scos-upgrade-guide

Before we begin, I’m far from a Dell Storage engineer and if something goes haywire, it is no loss to me as this unit will no longer be used for any of our workloads. Use this guide with caution as I take no responsibility for any problems or challenges that you make encounter along the way.

With that out of the way, I started off by unzipping the SCOS R07.03.20.019.10, which is closest to my current version, to a folder on my desktop that will be running the update from.

I launched DSM, I went into Settings –> SupportAssit option. I disabled SupportAssist and enabled the Configure Update Utility and pointed the IP to that of my desktop that will be running the Dell Storage Center Update Utility. This is where the SCOS updates will be pulled from.

Afterwards, I launched the Dell Storage Center Update Utility from my desktop, pointed the Distro Directory to the location of the unzipped SCOS files. I then pressed the START button to begin validation of the files.

Now going back into DSM, I will manually check for updates and this is what I see:

DSM detects the available SCOS update from my transmit client. I will select the Apply all updates option since I don’t have any services that would be impacted. I will begin the upgrade and see how it works out. I’ll be sure to update my post as I work through the following SCOS:

  • R07.03.20.019.10
  • R07.04.21.004.02
  • R07.05.10.012.01

Edit 1:

I couldn’t perform the update because the Dell Storage Manager client (2018 R1.10, build 18.1.10.171) was too old for the new SCSO version. I upgraded the DSM client from 2018 R1.10 to 2018 R1.20 and restarted the update.

That had worked as it is asking me for the Admin password now.

After about 10-15 minutes, the update completed successfully.

Logging back into DSM, I see this message.

Its possible this is a new feature that we didn’t know of due to the outdated SCOS, or it was disabled and this version informs us of this.

Next, I will try to update to SCOS: R07.04.21.004.02

Back on my desktop, I changed the Distro Directory in the Storage Center Update Utility to point to the SCOS version that I will work on deploying next (R07.04.21.004.02). Make sure to unzip all of the files.

I see the following message in the info log stating the version was validated.

Starting the update the same way as before, it looks like it will run. If it does error out, it may be due to the DSM software version.

Lets see how it goes…

Edit 2:

Just as I thought, I will need to update DSM.

I have version 20.1.2.14 so I will try that.

With DSM 2020 R1.2, the update is now starting to run.

While this upgrade is running, it did provide an error but the process was still running. This update took the longest because I mistakenly left the Selected Installation Type set as Non-Service Affecting.

After a bit of time, the update completed.

The last and final upgrade will be to version R07.05.10.012.01.

I unzipped the folder contents and mounted the files with the Storage Center Update Utility.

I went back into DSM and checked for updates. Below is the final update available and pending. This time I made sure to select Apply all updates – service affecting.

I let DSM do its thing and after a bit of time, the completed message was showing and the final SCOS update was installed.

That is pretty much it for the updates. I am not sure if the SCV2000 series has newer updates than 7.5.10.12.

This is a bit of an involved process if you don’t have an active support contract so I hope this can help somebody out there. It was a fun exercise and something I’ve wanted to do for a while.

Thank you reading this.

VMware ESXi – Cannot add VMFS datastore

To give some greater context, see my previous post.

When I was initially planning on how to setup these drives, I configured them with the HP P410 RAID utility as a RAID-0 array. I made the decision to not live such a risky lifestyle and blow away the array and configure it for RAID-1. I want to build a solid homelab that will assist me in aspects of systems administration so I didn’t want to risk everything by running the wrong array.

Anyways, when I booted into VMware, I was unable to add the VMFS datastore after setting it to RAID-1.

I received the following error:

“Failed to create VMFS datastore – Cannot change the host configuration”

As seen by VMware ESXi

I did a bit of searching around and tried to re-scan the datastore and get vmwre to detect it but nothing was working. I soon came across the following VMware communities post here, user Cookies04 was on onto something.

The user identified a very familiar scenario to mine.

From what I have seen and found this error comes from having disks that were part of different arrays and contain some data on them.”

That’s the exact thing that happened to me. RAID-0, some VMware data, then RAID-1.

I proceeded to follow the three easy steps and my issue was solved.

To correct the reported problem

I didn’t really have to post all of this but I wanted to in case somebody were to come across my page and had the same issue.

The interwebz if filled with many many solutions for issues. I’m just adding what’s worked for me.

🙂