Create an LVM Volume Group Without Guessing Which Disks Will Be Wiped

You will create a new LVM volume group from one or more physical volumes, then verify its name, member devices and extent layout. The examples match LVM 2.03.16(2), package lvm2 2.03.16-3ubuntu3.2, installed on this machine.

Allow 15 minutes for a prepared test device, or longer if you still need to identify and initialise disks. You need the lvm2 tools, a shell, and root privileges for operations that write LVM metadata. This guide assumes the devices can be used for LVM and that you have checked their contents first.

1. Identify the devices before touching them

List block devices and their existing signatures. Use stable identifiers where your deployment has them, but first confirm what each path actually represents:

$ lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,UUID,MOUNTPOINTS
$ sudo wipefs --no-act /dev/sdb

The second command is a read-only inspection. It reports signatures that a later initialisation might remove. Do not proceed if the device is mounted, contains a filesystem you need, belongs to an existing volume group, or is otherwise not disposable for this operation.

vgcreate accepts physical volume paths as positional arguments. If a device is not already a physical volume, the command can initialise it as one. That convenience is also the main danger: you do not have to run pvcreate separately for a new device, but you must still approve the device choice yourself.

2. Preview the command with test mode

Use --test before the real change. It disables metadata writing while allowing the command to exercise its normal path:

$ sudo vgcreate --test data_vg /dev/sdb /dev/sdc
  TEST MODE: Metadata will NOT be updated and volumes will not be activated.
  Volume group "data_vg" successfully created

Exact diagnostic text can vary with the host configuration. The meaningful checkpoint is the exit status and the absence of an error identifying the devices or volume group name:

$ printf '%s\n' "$?"
0

Test mode is not a complete simulation. The manpage warns that multi-stage operations can produce unusual messages because metadata that a tool expects to have changed has not changed. Treat it as a pre-flight check, not as proof that the live operation cannot fail.

3. Create the volume group

When the device list and name are confirmed, run the same command without --test:

$ sudo vgcreate --autobackup y data_vg /dev/sdb /dev/sdc
  Volume group "data_vg" successfully created

--autobackup y asks LVM to back up metadata after the change. Automatic metadata backups are strongly advised by the manpage. The command also creates physical volume metadata when needed and creates the volume group metadata; it does not create a filesystem or logical volume.

Do not add --yes casually. It answers confirmation prompts automatically, and --force overrides checks and protections. The default --zero y behaviour wipes the first four sectors, 2048 bytes, of a device unless certain restore options are used. That is another reason to verify every path before pressing Enter.

Recovery boundary: if this was the wrong device, stop immediately. Do not run pvremove, vgremove or another forceful command as an improvised undo. Preserve the device state and recover from the appropriate storage or metadata backup. For a deliberately created empty test group, removal is a separate destructive operation and should only be done after confirming that it contains no required logical volumes.

4. Verify the group and its physical volumes

Use the reporting commands to check what LVM recorded:

$ sudo vgs -o vg_name,vg_size,vg_free,pv_count,lv_count
  VG       VSize  VFree #PV #LV
  data_vg  1.82t  1.82t   2   0
$ sudo pvs -o pv_name,vg_name,pv_size,pv_free
  PV         VG       PSize  PFree
  /dev/sdb   data_vg  931.50g 931.50g
  /dev/sdc   data_vg  931.50g 931.50g

Your sizes will differ. The useful result is that the expected paths belong to data_vg, the physical volume count is correct, and no logical volume has appeared by accident. For a more focused check, ask for the volume group's details:

$ sudo vgdisplay data_vg

Check the physical extent size shown there. LVM uses that size to divide the physical volumes into allocation units. The default is normally suitable for ordinary groups, but changing it later can require recreating the group unless no extents need moving.

5. Choose the less obvious options deliberately

For most new groups, the simple command is the right starting point. Add an option only when a storage design requires it.

• --physicalextentsize 1G sets the physical extent size. It must meet LVM's power-of-two and minimum-size rules, and it is difficult to change after creation.
• --maxlogicalvolumes N and --maxphysicalvolumes N impose limits. A value of zero removes the physical-volume limit, according to the manpage. These are policy limits, not extra capacity.
• --metadatatype lvm2 selects the current standard metadata format. The old lvm1 format is no longer used.
• --shared is for a shared group managed through lvmlockd. It requires the lock daemon and a lock manager to be configured and running. Do not use it merely because two hosts can see the same disks.
• --systemid VALUE overrides the host system ID. A mismatch can leave the new group inaccessible to the host, so leave this option alone unless you have a documented system-ID design.

Device filtering can also change what LVM sees. --devices /dev/sdb,/dev/sdc restricts the command to listed devices, while --devicesfile FILE selects an LVM devices file under /etc/lvm/devices/. If a device appears missing despite existing, inspect those controls before retrying with --force.

6. Confirm the metadata backup exists

Because the creation command changed metadata, check the backup location configured by LVM:

$ sudo find /etc/lvm/backup -maxdepth 1 -type f -name 'data_vg' -print
/etc/lvm/backup/data_vg

The exact directory can be changed in lvm.conf, so a missing file in that path is a prompt to inspect the configuration and command output, not permission to continue blindly. Keep the backup with the rest of the host's recovery material. It describes LVM metadata; it is not a filesystem backup.