Once upon a time, Adam Tauno Williams <awilliam@xxxxxxxxxxxxx> said:
> There may be numerous commands... but isn't it pretty obvious what each
> one of them do? Often lv<tab><tab> is plenty of hinting to get to the
> right thing. And each of the commands uses the same syntax for
> options.
The key thing is to know the LVM architecture. Once you have a basic
grasp of that, the rest is usually pretty easy to figure out.
At the bottom, you have some block device. This is most often a
standard disk partition (e.g. /dev/sda2); in some cases, it may be a
whole disk (e.g. /dev/sdb).
The first layer of LVM is the physical volume (PV). This is basically
"importing" a block device into the LVM stack; the PV uses the name of
the underlying block device (so still /dev/sda2 or /dev/sdb).
You put one or more PVs into a volume group (VG), and give it a name
(e.g. "vg_myhost", but there's nothing special about putting "vg_" at
the front, that's just something some people do). This is where the
functionality and flexibility starts to come into play. A VG can have
multiple PVs and spread data across them, do RAID, move blocks from one
PV to another, etc.
You then divide up a VG into logical volumes (LVs), also giving them
names (e.g. "lv_root"; again, "lv_" is just a common naming scheme, not
a requirement). This is where you can do snapshots, thin provisioning,
etc.
At that point, you'll have a new block device, like
/dev/vg_myhost/lv_root, and you can make filesystems, assign to VMs,
set up swap, etc.
The commands at each layer of LVM follow a similar scheme, so there's
pvcreate, vgcreate, and lvcreate for example. The arguments also follow
a common scheme. For the regular admin stuff, you can typically figure
out with a "--help" what you need (using the man page as a refresher or
extended reference).
It's basically a way to assemble one arbitrary set of block devices and
then divide them into another arbitrary set of block devices, but now
separate from the underlying physical structure.
Regular partitions have various limitations (one big one on Linux being
that modifying the partition table of a disk with in-use partitions is a
PITA and most often requires a reboot), and LVM abstracts away some of
them. LVM is a set of commands and modules layered on top of the Linux
kernel's "device mapper" system. DM is just a way to map block A of
virtual device X to block B of physical device Y; at one point, there
was some discussion of kicking partition handling out of the kernel and
just going with DM for everything (requires some form of init ramdisk
though which complicates some setups).
--
Chris Adams <linux@xxxxxxxxxxx>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
