[feature] Intel RSTe/VROC hardware-assisted software RAID support (aka FakeRAID)

[Trent Lloyd]

(Some, Many?) Intel systems support a hardware-assisted software raid called "RSTe", it is hardware assisted in that the arrays can be managed partly from within the BIOS and assists during boot time but once the OS starts it needs to support the RAID operations directly similar to how standard software RAID works.

mdadm has support for RSTe, and will automatically detect and setup such arrays. It appears that you setup the RSTe RAID in the bios/option rom for the RAID and it writes the headers onto the disks that mdadm reads and sets up automatically.

In a MAAS environment, mdadm does detect these arrays, but obviously MAAS intends to control the RAID configuration so wants to wipe it instead. It could perhaps instead import this configuration - however implementation wise it would probably need to learn not to wipe the existing configuration when trying to deploy it. It is possible to create a fresh RAID configuration in this format using mdadm (the commands are different to a normal mdadm creation) however it's not clear how well that would work over using the metadata already setup by the option ROM.

This request comes from a customer who had Supermicro SYS-5038ML-H12TRF with Super X10SLE-F Boards (C224 chipset) however this feature is supported on a wide array of Intel chipsets including at least Intel X79, C222, C224, C226, C602, C602J, C604, C606 and C608.

To avoid confusion when looking at terms, this was previously known as "Matrix RAID" circa 2010 but renamed RST - Rapid Storage Technology (for desktop systems) and RSTe (e=enterprise) for the enterprise version on server systems.

Documentation from Intel on this feature:
[1]: https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/rapid-storage-technology-enterprise-brief.pdf
[2]: https://www.intel.com/content/dam/support/us/en/documents/chipsets/rste/sb/intelr_rste_linux.pdf
[3]: https://medium.com/@pmarrapese/arch-linux-and-intel-rst-fake-raid-cece10b61ac3

[Mike Pontillo (mpontillo)]

Thanks for the feedback; this sounds like it could be a valuable enhancement to MAAS. We should discuss separately from this bug if it can be put on the roadmap.

[Andres Rodriguez (andreserl)]

Hi Trent,

I just wanted to add to Mike's response.

This is not supported as part of our product suite (MAAS/Curtin/Ubuntu Server). Our recommended solution for this type of hardware is to use Software RAID instead.

[Mike Pontillo (mpontillo)]

When I read "hardware-assisted software raid" I understood that it would actually improve performance, but talking to others, I understood that this is a metadata-only assistance. If that's the case, why would you want to do this? Wouldn't it be better to have the metadata on-disk instead of in the BIOS, in case you need to swap out the motherboard? In other words, the disks would be usable on any machine that supports `mdadm` if the metadata is on-disk and not managed by a [Fake]RAID controller.

[Trent Lloyd (lathiat)]

The metadata is in fact stored on the disks, though in a different format to that of mdadm traditionally. The BIOS assists in letting you setup that metadata from the BIOS, though, you can also write to it with mdadm (you can do either).

The hardware assistance is that there is a BIOS and/or UEFI storage driver which supports the RAID so that e.g. the boot loader is installed on one disk and automatically written to the other - and during boot the BIOS will read the boot loader from either and the boot loader etc also can. Along with anything else using the basic BIOS disk commands (perhaps a firmware flash utility using DOS?). This support is low performance (the microcontroller/firmware doing it is slow) but that's OK as the operating system takes over as soon as it starts for high performance.

With traditional software RAID you don't get that and have to instead tell the BIOS to attempt booting from both disks and install the boot loader separately on both disks. You can also have failures where the boot doesn't proceed to the second non broken disk in some cases. That's the major difference as I understand it.

Outside of Linux, this RSTe support also works for Windows -- and the customer that requested this feature is specifically using MAAS to deploy Windows images. Software RAID is not an option there currently as best I understand.

I fully appreciate that this isn't supported currently, which is why it is a feature request and I advised the customer the same. They are simply not using the RAID for the deployment at this time.

[Mike Pontillo (mpontillo)]

Thanks for the clarification on the reasons for this requirement. Sounds like this would be nice-to-have.

[Adam Collard (adam-collard)]

This bug has not seen any activity in the last 6 months, so it is being automatically closed.

If you are still experiencing this issue, please feel free to re-open.

MAAS Team

[György Szombathelyi (gyurco)]

It would be interesting, I'll try to "borrow" a VROC-enabled server for some days. I think it will be not too hard to add this to curtin. I'll have questions about the preferred method how to present this to the user, e.g. maybe an external_metadata: xxxx, where xxxx could be imsm for now could execute this 2 stage raid array creation.
About the MaaS part: I would leave it to MaaS developers, I'm not sure what should be done there. I think it will need a detection method in the commissioning phase at least.

[György Szombathelyi (gyurco)]

Added the comment to the wrong report, sorry...

[Nobuto Murata (nobuto)]

From Intel's announcement back in 2019:
> * Only the Intel® VROC name will remain and include all functionality
> - The Intel® RSTe name will no longer be used
> * The actual support and functionality on a given platform will not change
> * Functionality will depend on the HW/chipset/CPU in a given platform