| Summary: | Docker vg built from ephemeral storage does not activate on boot | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jake Hunsaker <jhunsaker> |
| Component: | lvm2 | Assignee: | LVM and device-mapper development team <lvm-team> |
| lvm2 sub component: | Default / Unclassified | QA Contact: | cluster-qe <cluster-qe> |
| Status: | CLOSED INSUFFICIENT_DATA | Docs Contact: | |
| Severity: | unspecified | ||
| Priority: | unspecified | CC: | agk, amurdaca, heinzm, jbrassow, jhunsaker, lsm5, lvm-team, msnitzer, prajnoha, prockai, thornber, vgoyal, zkabelac |
| Version: | 7.3 | Keywords: | Extras |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-07-28 03:44:46 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: | |
| Bug Depends On: | |||
| Bug Blocks: | 1420851 | ||
|
Description
Jake Hunsaker
2016-12-06 18:21:29 UTC
Is this really a docker issue or is this more of an LVM issue? This sounds like an LVM issue if VG does not activate automatically during boot. Or may be it is a setting issue to make sure VG activates during boot automatically. As of now, docker-storage-setup does not do anything to activate volume group during reboot and it assumes that lvm will take care of activating VG. Is it just the docker volume group which does not activate automatically. Do other volume groups activate. I suspect this is the issue of system wide (or per volume group) setting in system which decides whether volume group should be activated automatically on boot or not. Is there a per volume group setting to enable this? It is just the docker VG that does not activate. What do you mean by ephemeral storage here? Is that ephemeral storage available after reboot but volume group does not activate? ephemeral meaning provisioned from storage local to the node instead of one of the OSP storage components. Correct, storage is available but VG does not activate. I'd propose to first make terminology clear. There is no such thing as 'active' VG. It's ONLY LV which is active. When there is 'active' LV in VG - we 'may' just call such VG to be active. So when we talk about 'auto activation' of DockerVG - what does it exactly means ? Unsused thin-pool alone is not 'auto-activated' LV. LVM does auto-activate only 'ThinLV' (from lvm2 POV there is no reason to activate virtually unused thin-pool LV which has transaction-id == 0 in lvm2 metadata). ThinLV is not used by Docker. So now - what exactly is not activated ? Existing 'lvs -a' ? Wanted 'lvs -a' ? If you're not using lvmetad, then there's no LVM autoactivation. Make sure you have lvmetad properly configured - check lvmconfig --type current global/use_lvmetad. Based on comment #10, the configuration is wrong - the use_lvmetad is placed incorrectly in the lvm.conf file, however, in this case LVM should fallback to default operation (which is use_lvmetad=1). Please could you tell us if your issue is resolved after correcting the lvm.conf file? Customer abandoned the support case after we mentioned the lvm.conf issues. At this point we could probably close as INSUFFICIENT_DATA. (In reply to Jake Hunsaker from comment #13) > Customer abandoned the support case after we mentioned the lvm.conf issues. > At this point we could probably close as INSUFFICIENT_DATA. ok, will do. |