Bug 1113207
Summary: | [RFE] Support the rootfs to be a writable snapshot of a thin volume | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Fabian Deutsch <fdeutsch> | |
Component: | anaconda | Assignee: | Jiri Konecny <jkonecny> | |
Status: | CLOSED ERRATA | QA Contact: | Release Test Team <release-test-team-automation> | |
Severity: | high | Docs Contact: | Petr Bokoc <pbokoc> | |
Priority: | medium | |||
Version: | 7.0 | CC: | atodorov, bmcclain, dfediuck, fdeutsch, jkonecny, lmiksik, mbanas, mganisin, pbokoc, pkotvan, qiyuan, rbarry, riehecky, salmy, sbueno, weiwang, ycui | |
Target Milestone: | alpha | Keywords: | FutureFeature, OtherQA | |
Target Release: | 7.2 | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | anaconda-21.48.22.115-1 | Doc Type: | Enhancement | |
Doc Text: |
You can now create thin logical volume snapshots during the installation process
This update adds support for a new Kickstart command, "snapshot". This command allows you to create a LVM thin volume snapshot either before or after the installation. Available options are:
* `<vg_name>/<lv_name>` Specify the name of the volume group and logical volume to make a snapshot of.
* `--name=` Specify a name for the snapshot.
* `--when=` Specify `pre-install` if you want to take a snapshot before the installation begins, which can be useful if you want to preserve the state of a system before an upgrade. Alternatively, specify `post-install` to take a snapshot of a newly installed system before any additional changes are made to it.
All three options are mandatory. Also note that you can use this command multiple times in a single Kickstart file to take a snapshot both before and after the installation, or to take snapshots of multiple logical volumes. Make sure that each `-name=` parameter specifies a unique name when doing so.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1243906 1444059 (view as bug list) | Environment: | ||
Last Closed: | 2017-08-01 08:50:51 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | 1413942, 1432012 | |||
Bug Blocks: | 1082754, 1172230, 1191019, 1205794, 1243906, 1444059 |
Description
Fabian Deutsch
2014-06-25 15:55:19 UTC
This is something that blivet needs to implement, if it doesn't already. Blivet has support (on master branch) for creating LVM snapshots. Most of the logic requested by this RFE is going to live in anaconda and possibly pykickstart as I see it -- especially since there is no UI (existing or planned) in anaconda for creating snapshots. That sounds amazing. And the lack of UI is likely not a problem for us, as we (a) would add custom spokes and (b) wouldn't expose this functionality in the UI anyway. Solving this in anaconda would really help us. The plan is to roll out the rootfs in a thin LV using a liveimg, once that is rolled out a thin ansphot of that thin LV is taken and used as the rootfs. That way we preserve the original root tree Let's see if I have this straight: 1. use liveimg payload to install to a thin root lv 2. create a writeable snapshot of root lv 3. put the snapshot into /etc/fstab, &c instead of the original root lv Is that the whole thing? If so, that could quite easily be implemented using a %post that creates a snapshot, runs sed on the freshly installed system's /etc/fstab, then runs dracut to update initrd(s). (In reply to David Lehman from comment #6) > Let's see if I have this straight: > > 1. use liveimg payload to install to a thin root lv > 2. create a writeable snapshot of root lv > 3. put the snapshot into /etc/fstab, &c instead of the original root lv > > Is that the whole thing? Yes. That is the whole thing. > If so, that could quite easily be implemented using > a %post that creates a snapshot, runs sed on the freshly installed system's > /etc/fstab, then runs dracut to update initrd(s). That is our current approach which we use (but it's not yet working correctly) for testing and developing all of the tooling. But to make the consumption of this usage pattern easier, we'd like to get this included into anaconda. Maybe as an option to liveimg or to the thinp related storage configuration. Moving it to anaconda, because according to comment 3 the support in blivet is there, it just needs support in pykickstart and anconda itself. Prototyping is in progress. Hi Fabian, Could you please describe step-by-step instructions how to retest this bug, or could you retest this bug once it's fixed? Yes, I can re-test this this bug and here are also the steps to reproduce this: 1. Install RHEL on a thinp layout with this snapshot feature enabled (possibly by setting a ks directive flag) 2. Boot into the installed OS 3. Run lsblk and look for a layout similar to this: sdX ├─sda1 … ├─vg_fdeutschlapto-thinpool_tmeta │ └─vg_fdeutschlapto-thinpool-tpool │ ├─vg_fdeutschlapto-thinpool │ ├─vg_fdeutschlapto-Original │ ├─vg_fdeutschlapto-Layer--01 Tho I am not sure what the names of the LVs will look like (Original and Layer-01 in the example above). Is there any progress on this? There was a POC ... but it's developemnt have stalled. It's worth noting that this will change the bootloader configuration in /boot. Removing the LP for now, because we are now taking a snapshot in the %post part of a ks. For reference: We are doing this now in the %post part of a kickstart with the following code: https://gerrit.ovirt.org/gitweb?p=imgbased.git;a=blob;f=src/imgbased/imgbase.py;h=be7d2e8a3c72882840f3ffc76f38eb7431d45433;hb=HEAD This is creatign the following layout: centos/root centos/our-nvr-based-scheme-1.0-0 <-- Snap of centos/root centos/our-nvr-based-scheme-1.0-0+1 <-- Snap of centos/our-nvr-based-scheme-1.0-0 We'll then create a boot entry pointing to centos/our-nvr-based-scheme-1.0-0+1 Hello Fabian, I think we can add kickstart command for snapshot creation. About using writable snapshot as /, it seems easier to me and better to use / and create the snapshot after the installation when everything is set. It has two advantages, it's less aggressive change on the Anaconda side but also from my understanding (I'm no LVM expert) it's more support way of doing snapshots from the LVM side. Is this usable solution for your use-case? Jirka The methology suggested in comment 24 is also valuable, but does not align with what we are now using in RHEV-H. I am not sure if we could migrate our current mechanism to the method described in comment 24. In the end making the suggested change in comment 24 would not help us specifically, but when it is around, then we might consider to move to that mechanism. Anaconda PR: https://github.com/rhinstaller/pykickstart/pull/152 Pykickstart PR: https://github.com/rhinstaller/pykickstart/pull/152 Oops bad link, this is the good one: Anaconda PR: https://github.com/rhinstaller/anaconda/pull/1002 In process of backporting this feature to master, I found myself a bug. The UUID generator for an XFS snapshots worked only for a post-installation snapshots, it didn't change UUID for a pre-installation snapshots. Issue is fixed by PR: https://github.com/rhinstaller/anaconda/pull/1059 For this fix to work properly this Blivet's PR is required to be merged: https://github.com/rhinstaller/blivet/pull/589 Jirka Hi Jirka, can you please take a look at the Doc Text (for Release Notes) and let me know if it's fine? Thanks! Hi Petr, It looks fine I just have two ideas for an improvement. * Move the '--name' as the first parameter because it is lets say more significant. * The '--when=[pre-install|post-install]' parameter is slightly confusing to me. I would need to think if it is mandatory to specify 'pre-install|post-install' (it is mandatory) or I can use it as '--when' and it will default to something. Otherwise it looks great to me! Jirka I was not able to verify this bug due to a bug 1463198. This as actually not blocked by bug 1463198 after all. I was able to verify the current solution on RHEL-7.4-20170616.3 with anaconda-21.48.22.120-1.el7. Thanks. 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. https://access.redhat.com/errata/RHBA-2017:2293 |