Bluemix virtual machine Docker runs container

Recently played docker on Bluemix virtual machine, but found that the default installation uses loop-lvm mode for back-end storage, this is right for the next experiment. It will have an impact, and the docker official does not recommend using loop-lvm in the production environment. The following picture shows the advantages and disadvantages of the storage scheme given by the docker official:

So let’s share today. How to change the docker's devicemapper storage mode to direct-lvm.

docker first ran on ubuntu and debian, using aufs memory. Because docker is becoming more popular, many companies want to use it on RHEL, but the upstream kernel does not include aufs, so rhel can't use aufs. The developers eventually developed a new backend storage engine devicemapper, based on the existing Device Mapper technology, and made docker support pluggable. There are many real world cases where devicemapper is used in production environments. Device Mapper is a kernel-based advanced volume management technology framework for Linux systems. Docker's devicemapper storage driver is based on the framework's thin provisioning and snapshot capabilities for image and container management.

devicemapper is the default storage driver for Docker Engine under Red Hat Enterprise Linux. It has two configuration modes: loop-lvm and direct-lvm. Loop-lvm is the default mode, but if it is in production environment. Docker is deployed and is not officially recommended. We can use the docker info command to see the following warning:

WARNING: Usage of loopback devices is strongly discouraged for production use. Either use `–storage-opt dm.thinpooldev` or use `–storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning.

Direct-lvm is the recommended mode for Docker-recommended production environments, using block devices to build thin pools To store data for mirrors and containers.
The operating system for this article is Centos 7.2, the version of docker is 1.12, and the version of devicemapper is device-mapper-1.02.107-5.el7.x86_64.

1. Stop the Docker service

First run docker info to view the current system's docker configuration:

# root at bastion.shanker in ~ [15:03: 10]# docker infoContainers: 6 Running: 0 Paused: 0 Stopped: 6Images: 40Server Version: 1.10.3Storage Driver: devicemapper Pool Name: docker-253:0-11668417-pool Pool Blocksize: 65.54 kB Base Device Size: 10.74 GB Backing Filesystem: xfs Data file: /dev/loop0 Metadata file: /dev/loop1 Data Space Used: 3.641 GB Data Space Total: 107.4 GB Data Space Available: 103.7 GB Metadata Space Used: 5.972 MB Metadata Space Total: 2.147 GB Metadata Space Available : 2.142 GB Udev Sync Supported: true Deferred Removal Enabled: true Deferred Deletion Enabled: true Deferred Deleted Device Count: 0 Data loop file: /var/lib/docker/devicemapper/devicemapper/data WARNING: Usage of loopback devices is strongly discouraged for Production use. Either use `--storage-opt dm.thinpooldev` or use `--storage-opt dm.no_warn_on_loop_devices=true` to suppress this warning. Metadata loop file: /var/lib/docker/devicemapper/devicemapper/metadata Library Version: 1.02.107-RHEL7 (2015-10-14)Execution Driver: native-0.2Logging Driver: journaldPlugins: Volume: local Network: bridge null hostKernel Version: 4.7.9-200.fc24.x86_64Operating System: Fedora 24 (Twenty Four) OSType: linuxArchitecture: x86_64Number of Docker Hooks: 2CPUs: 8Total Memory: 14.99 GiBName: bastion.shankerID: SWHZ:KSZ3:CQMS:W5HN:F33Z: HWU2: 2GUE: OQII: 7BSE: J62P: 6EMX: RHL4Username: shankerRegistry: https://index.docker.io/v1/Registries: docker.io (secure)
 
 
 Found that Storage Driver is Devicemapper, Data File and Metadata File are loop devices. Let's stop docker:
 
#systemctl stop docker
 
 2 Add a disk and create a thin-pool lv
 
 View the newly added disk
 
fdisk -l /dev/sdbDisk /dev/sdb: 21.5 GB, 21474836480 bytes, 41943040 sectorsUnits = sectors of 1 * 512 = 512 bytesSector size (logical/physical): 512 bytes /512 bytes I/O size (minimum/optimal): 512 bytes /512 bytes
 
 Create pv
 
# root at model.shanker in ~ [14:36 :01]# pvcreate /dev/sdb Physical volume "/dev/sdb" successfully created
 
Create vg
 
 
# root at model.shanker in ~ [14:37:49]# vgcreate docker /dev/sdb Volume group "docker" successfully created
 
Create data lv
 
 
# root at Model.shanker in ~ [14:41:00]# lvcreate --wipesignatures y -n thinpool docker -l 95%VG Logical volume "thinpool" created.
 
 Create metadata lv
 
 
# root at model.shanker in ~ [14:41:06]# lvcreate --wipesignatures y -n thinpoolmeta docker -l 1%VG Logical volume "thinpoolmeta" created.
 
Note that the pool size as a meta cannot exceed 16GB! ! ! 
 
 Convert pool to thin-pool
 Change the chunksize of thinpool lv to 512KB and clear the first 4KB bytes. 
 
 root at model.shanker in ~ [14:42:31]# lvconvert -y --zero n -c 512k --thinpool docker/thinpool --poolmetadata docker/thinpoolmeta WARNING Converting logical volume docker/thinpool and docker/thinpoolmeta to pool's data and metadata volumes. THIS WILL DESTROY CONTENT OF LOGICAL VOLUME (filesystem etc.) Converted docker/thinpool to thin pool.
 
Create a thinpool profile
 
 
# root at model.shanker in /etc/lvm/profile [14:45:42]# vi docker-thinpool.profile# root at model.shanker in /etc /lvm/profile [14:45:50]# pwd/etc/lvm/profile# root at model.shanker in /etc/lvm/profile [14:45:53]# cat docker-thinpool.profile activation {thin_pool_autoextend_threshold= 80thin_pool_autoextend_percent=20}
 
Application Configuration 
 
 
# root at model.shanker in /etc/lvm/profile [14:45:56]# lvchange - -metadataprofile docker-thinpool docker/thinpool Logical volume "thinpool" changed.
 
Note: docker-thinpool is just created Prefix of profile file name, no need to add .profile, and