Hide Forgot
Description of problem: Customer has reported that when using ephemeral storage from RHOS as the backing vg for docker, the VG does not activate on boot. Looking at https://access.redhat.com/solutions/22545, neither workaround suggested works (_netdev in fstab, etc...) and the bug for that KCS (BZ#1371692) is closed with errata. The customer can simply do a 'vgchange -a -y' and boot that in rc.local as a workaround, but ideally we should see why the VG is not activating on boot in the first place. Version-Release number of selected component (if applicable): docker-1.10 How reproducible: Easily for customer, I do not have a RHOSP environment to use to test this with myself. Steps to Reproduce: 1. Create RHOSP VM with ephemeral storage, using that storage for the backing VG given to docker-storage-setup 2. 3. Actual results: VG is not activated on boot, thus docker will not start Expected results: VG should activate and docker should start Additional info:
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.