Once upon a time, Adam Tauno Williams <awilliam at whitemice.org> 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 at cmadams.net>