Improving behaviour with pre-existing software-RAID devices

[ydirson]

Currently, udev rules in /lib/udev/rules.d/65-md-incremental.rules cause any pre-existing software-RAID devices to be auto-assembled, and the user cannot opt-out. As a consequence:

• disks that are part of a RAID array of disks cannot be selected for install
• a RAID array built from partitions can be selected for install (but installed system won't boot)
• disks with partitions that are part of a RAID array are available for selection, but install will fail

To solve this situations, our current plans for XCP-ng are:

• disable auto-assembly (eg. by causing the ANACONDA udev envvar to be set), solving all the above problems
• still allow user to enable RAID when needed, identified use cases including:
  • being able to upgrade or restore a system that was installed in RAID device (we already have support for such installs, not contributed yet, but I understand NetScaler has a use-case)
  • being able to install on a pre-existing RAID (would be the NetScaler use-case)

The basic idea for now is to probe the available disks for RAID superblocks (mdadm --examine), and when one is found, add an option besides the existing install/upgrade/restore/reinstall ones, to assemble any RAID volumes (mdadm --assemble --scan). An option for this would be provided to activate this behavior from answerfile.

This will notably require moving the "Checking for existing products" logic later, so it can be rerun. Its current location, before ensuring there are any disks in the system, already feels awkward; is there anything to be aware of around that area ?

[rosslagerwall]

In general, I think what you're suggesting is fine.

But wouldn't it make sense to put the RAID stuff in the F10 - set up advanced storage classes option near the beginning of installation? After this point it is expected that all drivers are loaded and additional disks (e.g. FCoE) are present.

[rosslagerwall]

I also think along with the IPv6 PR that this would ideally have a way of enabling/disabling the UI bits at build time so that we don't necessarily expose it to customers if we don't generally support it.

[ydirson]

But wouldn't it make sense to put the RAID stuff in the F10 - set up advanced storage classes option near the beginning of installation? After this point it is expected that all drivers are loaded and additional disks (e.g. FCoE) are present.

Currently it looks like "set up advanced storage classes" is just "setup FCoE", and F10 just sends a popup telling there are "no DCB capable interfaces" to most of us. How do you envision things ? Causing F10 to show a menu with different available technologies ?

[rosslagerwall]

Causing F10 to show a menu with different available technologies ?

There could be a simple menu like this which leaves scope for other advanced disk configuration in the future.

--------------------
|  Configure FCoE  |
|  Configure RAID  |
--------------------

In particular, iSCSI boot is this weird thing where you have to pass an additional command-line argument. It would make more sense to include it here too.

[ydirson]

Makes sense.
There will still be 2 aspects of RAID, namely:

1. what this PR covers after the disabling of auto-assembly, i.e. the usage of pre-existing RAID volumes (as need by NetScaler, and (nearly) incidentally also by our RAID-install support below
2. the ability to interactively create a RAID volume, for which we intend to submit a separate PR

I guess the way to go would be to have one feature-flag for each, so NS can trigger their RAID assembly, though XS may not want to activate it by default.
Maybe it could make sense to have the 2 entries live in the same menu as "Configure FCoE", like

----------------------------
|  Configure FCoE          |
|  Assemble existing RAID  |
|  Configure RAID          |
----------------------------

That could look better than having a separate RAID menu, which would in many cases only have a single entry.

[ydirson]

On second thought, the "assemble existing RAID" is only ever to be presented if we detected a RAID superblock on at least one disk. Which means that for this machine, it is not really "advanced storage" not rather "nominal". Having this choice hidden behind "advanced storage" can make the user think there is no existing install on this machine, and launch a clean install by mistake.

So I think we should only use the F10 menu for configuration of a new RAID, which seems to match your original proposal, and it should rather be a good thing to have the "assemble existing RAID" on the primary-disk screen, because it only appears when there is a RAID to assemble.