Bug 663647 - [RFE] Support allocation of space to be left unused in a LVM volume group
Summary: [RFE] Support allocation of space to be left unused in a LVM volume group
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda
Version: 6.0
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: 6.2
Assignee: David Lehman
QA Contact: Release Test Team
URL:
Whiteboard:
Keywords: FutureFeature, Triaged
Depends On:
Blocks: 607248 GSS_6_2_PROPOSED 703208 750638 756082 761078 790457 873441 874112
TreeView+ depends on / blocked
 
Reported: 2010-12-16 13:46 UTC by J.H.M. Dassen (Ray)
Modified: 2018-11-28 21:45 UTC (History)
10 users (show)

(edit)
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.
Clone Of:
: 790457 (view as bug list)
(edit)
Last Closed: 2012-06-20 12:35:12 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0782 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2012-06-19 20:34:54 UTC

Comment 1 J.H.M. Dassen (Ray) 2011-04-18 14:38:33 UTC
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
strategy.

4. How would the customer like to achieve this? (List the functional
requirements here)

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
implemented.

After kickstarting, a specified amount of space in a volume group is left
unused

6. Is there already an existing RFE upstream or in Red Hat bugzilla?

no

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)

Yes 

9. List the affected packages

anaconda

Comment 2 J.H.M. Dassen (Ray) 2011-04-18 14:42:15 UTC
Q. What is the nature and description of the request? (please provide any
additional details)

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.

Comment 4 Chris Lumens 2011-06-03 19:08:47 UTC
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.

Comment 6 Dominic Cleal 2011-06-03 19:32:29 UTC
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.

Comment 7 David Lehman 2011-06-03 19:53:52 UTC
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.

Comment 18 Alexander Todorov 2012-04-04 11:37:40 UTC
Tested with 0329.0 tree. See kickstart results here:
https://bugzilla.redhat.com/show_bug.cgi?id=790457#c2

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.

Comment 19 David Lehman 2012-04-20 20:52:02 UTC
    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.
    
    New Contents:
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.

Comment 21 errata-xmlrpc 2012-06-20 12:35:12 UTC
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.

http://rhn.redhat.com/errata/RHBA-2012-0782.html


Note You need to log in before you can comment on or make changes to this bug.