2. What is the nature and description of the request?
With RHEL 6, we now offer the ability to merge snapshots with their origin,
making for a very useful backup-restore mechanism when using LVM. However in
order to take snapshots, there must be free space left in the volume group, and
since this customer uses kickstart for all of their installations, they need a
way to leave free space in a volume group with kickstart. We have found a way
to do this using logvol --percent (but not without running into a number of
issues, see https://bugzilla.redhat.com/show_bug.cgi?id=651445). However, they
would prefer to have a method for allocating free space that doesn't involve
using whatever is left over after logvol creation, because this has some
problems that go along with it. More specifically, you have to specify the
logvols in such a way that doesn't use all of the space in the vg, but this is
often difficult to do without knowing the exact size of the disk and hard
coding the sizes in. Also it prevents you from using --grow effectively,
because then logvols would grow into the space you are trying to leave unused.
For these reasons, they would like to see anaconda offer some sort of method
that allows them to allocate a chunk of space, using either --size or
--percent, that should be left unused in the vg.
3. Why does the customer need this? (List the business requirements here)
Ability to layout lvm in such a way that allows for snapshots. This is to
satisfy their business requirement of having a backup/restore/disaster-recovery
4. How would the customer like to achieve this? (List the functional
The simplest way we've come up with would just be an option to volgroup that
leaves X amount of space unused. For example:
volgroup myvg pv.sda2 --freespace=10G
volgroup myvg pv.sda2 --freespacepercent=10
5. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
After kickstarting, a specified amount of space in a volume group is left
6. Is there already an existing RFE upstream or in Red Hat bugzilla?
7. How quickly does this need resolved? (desired target release)
6.1 or 6.2
8. Does this request meet the RHEL Inclusion criteria (please review)
9. List the affected packages
Q. What is the nature and description of the request? (please provide any
Provide a mechanism to reserve an absolute minimum amount of space to be
left in an LVM volume group from a RHEL kickstart. Calculations for growing
logical volumes should be based on (TotalSpace - ReservedSpace).
We're looking into using the LVM merge support in RHEL6 to provide a
rollback facility for upgrades, so a way to explicitly reserve space in a
volume group inside kickstart would be very useful.
As a workaround, we may be able to allocate an LV and then remove it after
to guarantee a minimum allocation of space, but it's a bit hacky. We use the
kickstart grow option for LVs with absolute min and max sizes, so this seems
to be the only way to guarantee availability on disks that are smaller than
the max size.
I see this is already filed as #663647 (private), so I'd like to request the same.
Q. Why do you need this? (List the business requirements here)
It is planned to use LVM snapshots to provide upgrade rollback
functionality. When using LV growing from kickstart to support systems with
different size disks, guaranteeing reserved space isn't easily possible.
Q How would you like to achieve this? (List the functional requirements here)
Perhaps a command similar to "logvol" that reserves space instead of
allocating it. Otherwise options added to "volgroup" to reserve a minimum
absolute or percentage value. After using it, the volume group would be
left with unallocated space.
Q.How quickly does this need resolved? (desired target release)
RHEL 6.2, ideally 6.1.
Q. Would you be able to assist in testing this functionality if implemented?
This should be possible based on the GPS allocation at the customer over the
next few months.
Here's an idea for an implementation that I think will give them what they want.
Instead of introducing any new kickstart commands, we introduce a new filesystem type called "Free" or "None", or "Unallocated", or whatever. Then you can use the existing part/logvol/raid commands with all their options for sizing but instead of passing --fstype=ext4, you pass --fstype=free. This could also give you the capability to specify which disk you want the freespace on (--ondisk), the ability to make it grow or use a certain percent, and so forth.
At first guess, this doesn't seem much more complicated than adding an additional FS subclass whose action methods are pass throughs. I'm sure there'll be more to it than that, but not too much. It also doesn't require making any pykickstart changes.
Would your suggestion mean that no partition or LV is created, rather than it simply being empty?
If so, then that makes sense to me and I'd suggest naming it "unallocated" to ensure there's no ambiguity between being empty/unformatted and not being created.
FWIW a *very* easy workaround would be to create an LV to lock the space you want to reserve (create it as swap to avoid having to edit /etc/fstab) and then remove it in %post. If you use autopart, however, this option is not valid.
Tested with 0329.0 tree. See kickstart results here:
Manual assignment of free space is not possible - you can't specify how much free space to reserve when creating the VG. You can however, not consume all of it.
Moving to VERIFIED.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Change: Two new options were added to the kickstart volgroup command to specify initially unused space in megabytes or as a percentage of the total volume group size. These options are only valid for volume groups being created during installation.
Result: Users can effectively reserve space in a new volume group for snapshots while still using the --grow option for logical volumes within the same volume group.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.