You disk is partitioned using the MBR partition table. The disk is partitioned as follows:

• sda1: Primary partition, formatted with a filesystem, mounted on /boot.

• sda2: Extended partition, containing the following logical partitions:

  • sda5 to sda12: Logical partitions, formatted as LVM physical disks.

• sda3: Primary partition. Cannot say whether it is formatted or not.

• sda4: Primary partition. Cannot say whether it is formatted or not.

The LVM physical disks sda5 to sda12 are members of the LVM volume group experiment.

The LVM volume group experiment contains a LVM logical volume named test. The LVM logical volume experiment-test is formatted as a LUKS container. The payload of the LUKS container is named experiment-test_crypt; it is formatted with a with a file system and mounted on /.

Note that:

• sda2 is an extended partition. It is simply a container for logical partitions, it cannot be formatted with a filesystem and mounted.

• The logical partitions sda5 to sda12 are all formatted as LVM physical disks and made members of the LVM volume group experiment. All the space in the LVM volume group experiment is allocated to the logical volume test, formatted LUKS.

The point of LVM is to decouple the sizes of physical units of storage (whole disks or partitions) from the size of logical volumes (which will often contain filesystems).

As a result, splitting a single disk into multiple partitions and then adding all of those partitions as LVM physical volumes (PVs) in the same volume group (VG) is not very useful, except as a typing exercise. You'll end up essentially back to where you started from - with a big block of undifferentiated storage you'll need to slice apart into useful chunks.

Each PV can only be a member of just one VG at a time. Since all your PVs are members of the experiment VG, the VG a you mentioned in the question apparently no longer exists, and that means the logical volume (LV) important that was supposed to be inside it is now gone and overwritten. Sorry.

Your description of your LVM setup seemed to be... frankly, backwards or perhaps inside-out to me. Hopefully the explanation below may help in getting the concepts straight.

To maximize the advantages of LVM on a new disk, you'd generally want to do one of two things:

• if a system disk, create whatever is necessary to satisfy the requirements of the system firmware (e.g. an EFI System Partition on UEFI systems, or /boot on very old BIOS systems whose firmware may not be able to handle the full size of the disk) and single large partition to cover the rest of the disk, to be used as a LVM PV. Even if the firmware places no particular restrictions (e.g. with BIOS-style booting with the latest version of GRUB with LVM and encryption support) you might want to create a non-LVM /boot partition to ensure that the bootloader component modules and the kernel & initramfs files vital for booting are definitely contained on a particular "boot disk" instead of "anywhere" on a big multi-disk LVM volume group, to make troubleshooting easier.

• if a data disk, you have the option of not using partitioning at all, but just using the whole disk as a LVM PV. This can be an advantage if the disk is actually a SAN LUN: if the LUN needs to be expanded, a whole-disk LVM PV can be extended on-the-fly. After the SAN administrator has increased the LUN size, only a few commands is needed to make immediate use of the expanded size, with no need to fiddle with the partition table first. The flip-side is that for other operating systems, a whole-disk LVM PV is not recognizable as a disk that contains valid data: such a disk may easily be accidentally reformatted if accessed with another operating system. To minimize that risk, you might create a single partition encompassing the entire disk, and use that as a LVM PV.

Having multiple PVs is not a big deal by itself, but you should have at least some specific reason for having more than one PV per physical disk. Reclaiming space used by a previous dual-boot OS installation is one such valid reason. Having multiple VGs where one would suffice, on the other hand, can be a pain.

Once you have one or more PVs, you can create one or more VGs. If you have just one disk, there is generally no reason to create more than one VG. If you have multiple physical disks, you'll need to decide whether there is an expected need to separate those disks from each other for any reason, or if you can assume that they will be kept together for the life of the data stored on them. If the disks can be kept together, you can add all their PVs into a single VG. This will give you one big pool of storage, which you can slice into LVs any way you want - as long as the VG has enough total space available, you can create a LV that extends beyond the limits of any single PV.

When using LVM, the LVs mostly take the place of traditional partitions as containers of filesystems. If you need to extend a LV, you can do it - even on-line - as long as your VG still has unallocated space in at least one of its PVs. And if you run out of unallocated space, you can add (yes, even hot-add) a new PV into the VG and then extend your LV(s) onto it.

Within the bounds of the VG, you can use the pvmove command to move the LVs around if necessary - even while the VG is active and the filesystems on the LVs are mounted and in use. You can migrate the data on a new, bigger physical disk by adding the new disk as a PV into the old VG, then using pvmove to move the data from the old disk(s) to the new one(s), then remove the old disk(s) from the VG once they are empty. All this can be done without unmounting anything.

If you expect that a particular disk would need to be moved to another system with data in it, then you create a separate volume group for that disk - or maybe not use LVM at all on that disk, if the other system is not another Linux system. That could be the only real reason to create more than one VG in an average Linux setup with LVM.

There are two ways to set up encryption together with LVM:

• you can encrypt the physical disk/partition before you set it up as a LVM PV, so that a single encryption passphrase will unlock all the LVs at once (Layering: disk -> partition -> encryption device -> PV -> LV)
• or you can first set up your PVs, VG and LVs, and then set up encryption on one or more LVs separately, allowing different LVs to have different encryption passphrases if needed. (Layering: disk -> partition -> PV -> LV -> encryption device)