Red Hat Bugzilla – Bug 888863
No apparent way to put LVM on top of RAID in new custom storage UI
Last modified: 2017-11-29 10:49:59 EST
I'm using the TC3 anaconda installer.
I want to make a mirrored /boot partition, and then a second mirrored partition with an LVM volume group on top of that (including / and /home partitions).
This seems relatively common and straightforward.
However, I can't figure out how to do it at all: there seems to be no option for LVM on top of RAID, as they're both presented at the same layer.
Currently the only way to do LVM on RAID is via kickstart. I've been trying to work on adding it, but there just isn't enough time.
In that case, I'm going to move this to Rawhide so it's tracked for the next release. This is what I do all the time when _not_ using Kickstart, for what it's worth. When using kickstart, I'm usually either deploying an ephemeral (replaceable) system or one with enterprise RAID hardware. The software raid setup for desktop systems, when I use the anaconda gui.
I can confirm this.
Actually, under Fedora 18 on raw disks, I can't even run the installer after I manually create an MD array in the console. Anaconda bombs-out.
If possible, there probably should be a button for 'advanced' configuration when multiple hard drives are detected that describes a few common multi-disk layouts:
/ on /dev/md0 (RAID-1)
The entire system will be mirrored. Performance will be the same as a single drive system, and it will be able to operate with only one disk in the array running.
/boot on /dev/md0 (RAID-1), one big / on /dev/md1 (<choose RAID level: 10/5/1/0>)
The /boot partition will be mirrored across all matching disks, and everything else will be on a raid <number> array. <explain characteristics of md1 array>
/boot on /dev/md0 (RAID-1), LVM on /dev/md1 (<choose RAID level 10/5/1/0>)
You get the idea, but this one mentions how the individual partitions will be able to be grown in the future. This should also be the default.
RAID levels should default based on the available number of disks, possibly in a different screen that describes each one and calculates available layouts/space.
My preference is for an Advanced mode which skips listing a bunch of possible end goals and turns the approach the other way around.
Right now, the UI is oriented at users who describe a high-level end state and the program figures out how to implement that. It might work to have that provide more options and show more information, but that makes it more confusing for non-experts while not necessarily making it easier for storage experts.
Instead, the advanced mode should work from the bottom up, disks to partitions to raid and lvm to filesystems on top. That way, people who know what they want and how to build it have a straightforward way to do so.
I know that's a more complicated approach, with effectively two separate code modules doing the same thing in different ways, but I think that this is an important enough area that it's worth it (for Fedora and for RHEL).
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
I saw that this was marked fixed in anaconda 19.22-1 but I don't see any obvious way to do this in Fedora 20 installer. Am I missing something or is this still not implemented?
Me too. The Fedora 20 anaconda storage configuration tool seems to start with the "mount point" abstraction, and only then it is possible to select the underlying storage type (LVM, RAID, partition, BTRFS), but I don't see any way how to make the "mount point" to be a LV with the underlying device being RAID-1.
Since it has been more than half a year since this bug has been "fixed" according to the above message, I am reopening this and changing the version to Fedora 20.
Step 4. Click Modify, select raid level.
Oh duh. I totally missed that little nugget tucked away there. Thanks for pointing that out and sorry for the confusion :)
Please note that it took more than 3 hours of manually creating different partitioning schemes (which cause Anaconda to crash on load), rebuilding media, and poking around with source trying to make it do what I wanted on F23 before discovering this option. That means this option is not intuitive or easy to use. Ordinary users have no hope of ever figuring this out. It's a terrible shame because it does work, once you spend many hours trying to figure it out.
Setting needinfo because I'd like a second opinion on reopening this bug.
It doesn't need reopening.
It is documented here:
The documentation could probably benefit from having some typical storage scenarios as separate sections instead of having to wade through the current if-this-then-that style.
This is easily addressed in a bottom-up way in the new Blivit-GUI option.