mirror of https://github.com/tLDP/LDP
393 lines
18 KiB
XML
393 lines
18 KiB
XML
<appendix id="appxlvm"><title>The LVM plug-in</title>
|
|
|
|
<para>The LVM plug-in combines storage objects into groups called containers.
|
|
From these containers, new storage objects can be created, with a variety of
|
|
mappings to the consumed objects. Containers allow the storage capacity of
|
|
several objects to be combined, allow additional storage to be added in the future,
|
|
and allow for easy resizing of the produced objects.</para>
|
|
<sect1 id="lvmimp"><title>How LVM is implemented</title>
|
|
<para>The Linux LVM plug-in is compatible with volumes and volume groups from
|
|
the original Linux LVM tools from Sistina Software. The original LVM is based on the
|
|
concept of volume groups. A volume group (VG) is a grouping of physical volumes
|
|
(PVs), which are usually disks or disk partitions. The volume group is not directly
|
|
usable as storage space; instead, it represents a pool of available storage.
|
|
You create logical volumes (LVs) to use this storage. The storage space of the LV can
|
|
map to one or more of the group's PVs.</para>
|
|
<para>The Linux LVM concepts are represented by similar concepts in the EVMS LVM plug-in.
|
|
A volume group is called a container, and the logical volumes that are produced are
|
|
called regions. The physical volumes can be disks, segments, or other regions.
|
|
Just as in the original LVM, regions can map to the consumed objects in a variety of ways.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="containerops"><title>Container operations</title>
|
|
|
|
<sect2 id="createlvmconts"><title>Creating LVM containers</title>
|
|
|
|
<para>Containers are created with an initial set of objects. In the LVM plug-in, the
|
|
objects can be disks, segments, or regions. LVM has two options for creating containers.
|
|
The value of these options cannot be changed after the container has been created. The
|
|
options are:</para>
|
|
<variablelist>
|
|
<varlistentry><term>name</term>
|
|
<listitem><para>The name of the new container.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>pe_size</term>
|
|
<listitem><para>The physical extent (PE) size, which is the granularity with which regions can be created. The default is 16 MB. Each region must have a whole number of extents.
|
|
Also, each region can have only up to 65534 extents. Thus, the PE size for the container
|
|
limits the maximum size of a region in that container. With the default PE size, an LVM
|
|
region can be, at most 1 TB. In addition, each object consumed by the container must
|
|
be big enough to hold at least five extents. Thus, the PE size cannot be arbitrarily large. Choose wisely.</para></listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
</sect2>
|
|
|
|
<sect2><title>Adding objects to LVM containers</title>
|
|
<para>You can add objects to existing LVM containers in order to increase the pool of
|
|
storage that is available for creating regions. A single container can consume up to 256
|
|
objects. Because the name and PE size of the containers are set when the container is
|
|
created, no options are available when you add new objects to a container. Each object
|
|
must be large enough to hold five physical extents. If an object is not large enough to
|
|
satisfy this requirement, the LVM plug-in will not allow the object to be added to the container.
|
|
</para>
|
|
</sect2>
|
|
|
|
|
|
<sect2><title>Removing objects from LVM containers</title>
|
|
<para>You can remove a consumed object from its container as long as no regions
|
|
are mapped to that object. The LVM plug-in does not allow objects that are in use to
|
|
be removed from their container. If an object must be removed, you can delete or
|
|
shrink regions, or move extents, in order to free the object from use.</para>
|
|
<para>No options are available for removing objects from LVM containers.</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2><title>Expanding consumed objects in LVM containers</title>
|
|
<para>In addition to adding new objects to an LVM container,
|
|
you can also expand
|
|
the space in a container by expanding one of the existing consumed
|
|
objects (PVs).
|
|
For example, if a PV is a disk-segment with freespace immediately
|
|
following it on
|
|
the disk, you can expand that segment, which will increase the
|
|
amount of freespace in the container.
|
|
Likewise, if a PV is a RAID-0 or RAID-5 region, you can expand
|
|
that region by adding additional objects, which in turn increases the
|
|
freespace in the container.</para>
|
|
<para>When using the GUI or text-mode UIs, PV-expand is performed by expanding
|
|
the container.
|
|
If any of the existing PVs are expandable, they will appear in the
|
|
expand-points list.
|
|
Choose the PV to expand, and then the options for expanding
|
|
that object. After the PV has expanded, the container's
|
|
freespace will reflect the additional space available on that PV.</para>
|
|
<para>When using the CLI, PV-expand is performed by expanding the
|
|
appropriate object directly.
|
|
The CLI and the EVMS engine will route the necessary commands so the
|
|
container is expanded at the same time.</para>
|
|
<para>The options for expanding a PV are dependent on the plug-in
|
|
that owns that PV object.
|
|
Please see the appropriate plug-in's appendix for more details on
|
|
options for that object.</para>
|
|
</sect2>
|
|
|
|
<sect2><title>Shrinking consumed objects in LVM containers</title>
|
|
<para>
|
|
In addition to removing existing objects from an LVM container,
|
|
you can
|
|
also reduce the size of a container by shrinking one of the existing
|
|
consumed objects (PVs).
|
|
This is only allowed if the consumed object
|
|
has physical extents (PEs) at the end of the object that are not allocated
|
|
to any LVM regions.
|
|
In this case, LVM2 will allow the object to
|
|
shrink by the number of unused PEs at the end of that object.
|
|
</para>
|
|
|
|
<para>
|
|
For example, if a PV is a desk-segment, you can shrink that segment,
|
|
which will decrease the amount of freespace in the container. Likewise,
|
|
if a PV is a RAID-0 or RAID-5 region, you can shrink that region by
|
|
removing one of the objects, which in turn decreases the freespace in
|
|
the container.
|
|
</para>
|
|
|
|
<para>
|
|
When using the GUI or text-mode UIs, PV-shrink is performed by shrinking
|
|
the container. If any of the existing PVs are shrinkable, they will
|
|
appear in the shrink-points list. Choose the PV to shrink, and then the
|
|
options for shrinking that object. After the PV has shrunk, the container's
|
|
freespace will reflect the reduced space available on that PV.
|
|
</para>
|
|
|
|
<para>
|
|
When using the CLI, PV-shrink is performed by shrinking the appropriate
|
|
object directly. The CLI and the EVMS engine will route the necessary
|
|
commands so the container is shrunk at the same time.
|
|
</para>
|
|
|
|
<para>
|
|
The options for shrinking a PV are dependent on the plug-in that owns
|
|
that PV object. Please see the appropriate plug-in's appendix for more
|
|
details on options for that object.
|
|
</para>
|
|
</sect2>
|
|
|
|
|
|
<sect2><title>Deleting LVM containers</title>
|
|
<para>You can delete a container as long as the container does not have any produced
|
|
regions. The LVM plug-in does not allow containers to be deleted if they have any
|
|
regions. No options are available for deleting LVM containers.</para>
|
|
</sect2>
|
|
|
|
<sect2><title>Renaming LVM containers</title>
|
|
<para>You can rename an existing LVM container. When renaming an LVM container,
|
|
all of the regions produced from that container will automatically have their names changed as
|
|
well, because the region names include the container name.
|
|
In the EVMS GUI and text-mode UIs, this is done using the
|
|
<command>modify properties</command> command,
|
|
which is available through the "Actions" menu or the context-sensitive pop-up menus.
|
|
In the EVMS CLI, this is done using the <command>set </command>command.</para>
|
|
<para>See <xref linkend="renamereg"></xref> for more information about the effects of renaming the regions.</para>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1><title>Region operations</title>
|
|
|
|
<sect2><title>Creating LVM regions</title>
|
|
<para>You create LVM regions from the freespace in LVM containers. If there is at least
|
|
one extent of freespace in the container, you can create a new region.</para>
|
|
<para>The following options are available for creating LVM regions:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry><term>name</term>
|
|
<listitem><para>The name of the new region.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>extents</term>
|
|
<listitem><para>The number of extents to allocate to the new region. A new region must
|
|
have at least one extent and no more than the total available free extents in the container,
|
|
or 65534 (whichever is smaller). If you use the <filename>extents</filename> option, the appropriate value
|
|
for the size option is automatically calculated. By default, a new region uses all
|
|
available extents in the container.</para></listitem>
|
|
</varlistentry>
|
|
|
|
|
|
<varlistentry><term>size</term>
|
|
<listitem><para>The size of the new region. This size must be a multiple of the
|
|
container's PE size. If you use the <filename>size</filename> option, the appropriate value for the
|
|
extents options is automatically calculated. By default, a new region uses all
|
|
available freespace in the container.</para>
|
|
</listitem></varlistentry>
|
|
|
|
<varlistentry><term>stripes</term>
|
|
<listitem><para>If the container consumes two or more objects, and each object has
|
|
unallocated extents, then the new region can be striped across multiple objects.
|
|
This is similar to RAID-0 striping and achieves an increased amount of I/O
|
|
throughput across multiple objects. This option specifies how many objects the
|
|
new region should be striped across. By default, new regions are not striped, and
|
|
this value is set to 1.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>stripe_size</term>
|
|
<listitem><para>The granularity of striping. The default value is 16 KB. Use this option
|
|
only if the <filename>stripes</filename> option is greater than 1.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>contiguous</term>
|
|
<listitem><para>This option specifies that the new region must be allocated on a single
|
|
object, and that the extents on that object must be physically contiguous. By default,
|
|
this is set to false, which allows regions to span objects. This option cannot be used
|
|
if the <filename>stripes</filename> option is greater than 1.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>pv_names</term>
|
|
<listitem><para>A list of names of the objects the new region should map to. By default,
|
|
this list is empty, which means all available objects will be used to allocate space
|
|
to the new region.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
</sect2>
|
|
|
|
<sect2><title>Expanding LVM regions</title>
|
|
<para>You can expand an existing LVM region if there are unused extents in the
|
|
container. If a region is striped, you can expand it only by using free space on
|
|
the objects it is striped across. If a region was created with the contiguous option,
|
|
you can only expand it if there is physically contiguous space following the
|
|
currently allocated space.</para>
|
|
<para>The following options are available for expanding LVM regions:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry><term>add_extents</term>
|
|
<listitem><para>The number of extents to add to the region. If you specify this
|
|
option, the appropriate value for the add_size option is automatically
|
|
calculated. By default, the region will expand to use all free extents in the
|
|
container.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>add_size</term>
|
|
<listitem><para>The amount of space to add to the region. If you specify this option,
|
|
the appropriate value for the add_extents option is automatically calculated.
|
|
By default, the region will expand to use all freespace in the container.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry><term>pv_names</term>
|
|
<listitem><para>A list of names of the objects to allocate the additional space from.
|
|
By default, this list is empty, which means all available objects will be used to
|
|
allocate new space to the region.</para></listitem>
|
|
|
|
</varlistentry>
|
|
</variablelist>
|
|
</sect2>
|
|
|
|
<sect2><title>Shrinking LVM regions</title>
|
|
<para>You can shrink an existing LVM region by removing extents from the end of the
|
|
region. Regions must have at least one extent, so regions cannot be shrunk to zero.</para>
|
|
<para>The following options are available when shrinking LVM regions. Because regions
|
|
are always shrunk by removing space from the end of the region, a list of objects
|
|
cannot be specified in this command.</para>
|
|
|
|
<variablelist>
|
|
<varlistentry><term>remove_extents</term>
|
|
<listitem><para>The number of extents to remove from the region. If you specify this option,
|
|
the appropriate value for the <filename>remove_size</filename> option is automatically calculated. By
|
|
default, one extent is removed from the region.</para>
|
|
</listitem></varlistentry>
|
|
|
|
<varlistentry><term>remove_size</term>
|
|
<listitem><para>The amount of space to shrink the region by. If you specify this option,
|
|
the appropriate value for the <filename>remove_extents</filename> option is automatically calculated.</para></listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
</sect2>
|
|
|
|
<sect2><title>Deleting LVM regions</title>
|
|
<para>You can delete an existing LVM region as long as it is not currently a
|
|
compatibility volume, an EVMS volume, or consumed by another EVMS plug-in.
|
|
No options are available for deleting LVM regions.</para>
|
|
</sect2>
|
|
|
|
<sect2><title>Moving LVM regions</title>
|
|
<para>The LVM plug-in lets you change the logical-to-physical mapping
|
|
for an LVM region and move the necessary data in the process.
|
|
This capability is most useful if a PV needs to be removed from a container.
|
|
There are currently two LVM plug-in functions for moving regions:
|
|
<command>move_pv</command> and <command>move_extent</command>.</para>
|
|
|
|
<sect3><title>move_pv</title>
|
|
<para>When a PV needs to be removed from a container, all PEs on that PV that are
|
|
allocated to regions must be moved to other PVs. The <command>move_pv</command> command lets you move PEs to other PVs.
|
|
<command>move_pv</command> is targeted at the LVM container and the desired PV is used as
|
|
the selected object. The following options are available:</para>
|
|
<variablelist>
|
|
<varlistentry><term>target_pvs</term>
|
|
<listitem><para>By default, all remaining PVs in the container are used to find
|
|
available extents to move the PEs. You can specify a subset of the PVs with this option.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry><term>maintain_stripes</term>
|
|
<listitem><para>When the target PV contains striped regions, there are three choices
|
|
for handling moving extents that belong to those regions:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry><term>no</term>
|
|
<listitem><para>Don't bother to maintain true striping. This choice allows
|
|
extents to be moved to PVs that the region already uses for other stripes.
|
|
This means that the performance will not be as optimal as it is with true
|
|
striping, but allows the most flexibility in performing the move operation.
|
|
This choice is the default for the <command>maintain_stripes</command> option.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry><term>loose</term>
|
|
<listitem><para>Ensure that moved extents do not end up on any PVs that the
|
|
striped region already uses. However, this does not ensure that all moved
|
|
extents end up on the same PV. For example, a region with three stripes may
|
|
end up mapping to four or more PVs.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
<varlistentry><term>strict</term>
|
|
<listitem><para>Ensure that all moved extents end up on the same PV, thus ensuring
|
|
true striping with the same number of PVs that the striped region originally used.
|
|
This is the most restricted choice, and may prevent the <command>move_pv</command> operation from
|
|
proceeding (depending on the particular configuration of the container).</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>If the target PV has no striped regions, the <command>maintain_stripes</command> option is ignored.</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</sect3>
|
|
|
|
<sect3><title>move_extent</title>
|
|
<para>In addition to moving all the extents from one PV, the LVM plug-in provides
|
|
the ability to move single extents.
|
|
This allows a fine-grain tuning of the allocation of extents.
|
|
This command is targeted at the region owning the extent to move. There are
|
|
three required options for the <command>move_extent</command> command:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry><term>le</term>
|
|
<listitem><para>The number of the logical extent to move. LE numbers start at 0.</para></listitem>
|
|
</varlistentry>
|
|
<varlistentry><term>pv</term>
|
|
<listitem><para>The target object to move the extent to.</para></listitem>
|
|
</varlistentry>
|
|
<varlistentry><term>pe</term>
|
|
<listitem><para>The target physical extent on the target object. PE numbers
|
|
also start at 0.</para></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
<para>To determine the source LE and target PE, it is often helpful to view the
|
|
extended information about the region and container in question.
|
|
The following are command-line options that can be used to gather this
|
|
information:</para>
|
|
<para>To view the map of LEs in the region, enter this command:</para>
|
|
<programlisting>query:ei,<region_name>,Extents</programlisting>
|
|
|
|
<para>To view the list of PVs in the container, enter this command:</para>
|
|
<programlisting>query:ei,<container_name>,Current_PVs</programlisting>
|
|
|
|
<para>To view the current PE map for the desired target PV, enter this command:</para>
|
|
<programlisting>query:ei,<container_name>,PEMapPV#</programlisting>
|
|
<para># is the number of the target PV in the container.</para>
|
|
|
|
<para>This information is also easily obtainable in the GUI and Text-Mode UIs by
|
|
using the "Display Details" item in the context-popup menus for the desired
|
|
region and container.</para>
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="renamereg"><title>Renaming LVM regions</title>
|
|
<para>You can rename an existing LVM region. In the EVMS GUI and text-mode UIs, this
|
|
is done using the <command>modify properties</command> command, which is available through the "Actions"
|
|
menu or the context-sensitive pop-up menus. In the EVMS CLI, this is done using the
|
|
<command>set</command> command.</para>
|
|
<para>If the renamed LVM region has a compatibility volume on it, then the name of that
|
|
compatibility volume will also change. In order for this to work correctly, that volume must
|
|
be unmounted before the name is changed. Also, be sure to update your
|
|
<filename>/etc/fstab</filename> file if the volume is listed, or the volume won't be mounted properly the next
|
|
time the system boots.</para>
|
|
<para>If the renamed LVM region has an EVMS volume or another storage object built on it,
|
|
then the region's name change will be transparent to the upper layers. In this case, the
|
|
rename can be done while the volume is mounted.</para>
|
|
</sect2>
|
|
|
|
|
|
</sect1>
|
|
|
|
</appendix>
|
|
|