27

It appears that I am able to successfully do a pvcreate on top of a raw block device, without ever taking the step of creating a partition table. I am then able to create a volume group, logical volume, and finally a filesystem, mount it, and test via dd.

It appears to work, but I need a sanity check. Is this a bad idea?

How do I create a GPT or MBR partition table on top of a raw block device?

How do I use parted to show what sort of partition table is in use? I have tried doing:

parted, select /dev/sdb, print and I get:

Error: /dev/sdb: unrecognised disk label

Yet the drive is currently in use and I can read and write to it. Is that the expected output when doing LVM on top of a raw block device without a partition table? Any thoughts?

Thanks!

cat pants
  • 2,139
  • 10
  • 33
  • 44

7 Answers7

34

Even if LVM itself doesn't care about having a real partition, one reason to create it anyway is to inform partitioning programs that there's "something there." A nightmare scenario is a new sysadmin diagnosing a boot problem on a server, firing up a partitioning program, seeing unpartitioned disks, and concluding that the drive is corrupt.

I see no downside to creating an LVM partition. Do you?

Philip
  • 781
  • 5
  • 10
  • 2
    +1 for the scenario. All too likely in real life. – Hennes Oct 16 '12 at 17:21
  • 2
    +1 for being insightful. – Alexander Janssen Oct 16 '12 at 18:59
  • 1
    Thanks for the reply! I certainly see no downside to having a partition table. I just wanted to confirm with a sanity check. So the correct order of layers is: block device, partition table, volume group, logical volume, filesystem, is that correct? – cat pants Oct 17 '12 at 17:32
  • 11
    The downside: If you expand the block device and did not use a partition table, you can immediately expand the physical volume with pvresize. If you used a partition table, you have to delete the partition and recreate it with the larger size first. – sciurus Apr 23 '14 at 19:46
  • 3
    Exercising caution is good, but throwing the question back does not make for a great answer. There is no need for this partition, and there are downsides to having a partition. – bryn Nov 27 '18 at 11:01
15

While you can just create a pv out of raw block device I normally try to avoid it as it can cause confusion as to what the block device is being used for. It may also break some of the auto discover routines that LVM can use if it's missing it's configuration files.

Here's an example of using parted to create a GPT with 1 partition that is the whole drive and set the partition flag to be lvm. The mkpart requires that you specify a file system but it doesn't create the file system. Seems to be a long standing bug in parted. Also the start offset of 1M is to ensure that you get proper alignment.

parted /dev/sdb
mklabel GPT
mkpart primary ext2 1M 100%
set 1 lvm on
3dinfluence
  • 12,409
  • 2
  • 27
  • 41
  • 3
    "The mkpart requires that you specify a file system but it doesn't create the file system." Thank you for mentioning this, that is HUGE in establishing sanity! :) – cat pants Oct 17 '12 at 22:45
  • 1
    No longer true. `mkpart primary 1M 100%` works and leaves File system field blank. – stark Jan 13 '15 at 15:21
  • 1
    @3dinfluence lvm now does alignment automatically, after many years I don't see the real use case to use a partition for data disk dicated for lvm – c4f4t0r Jan 22 '19 at 02:52
7

Even if in the past I was using MS-DOS disklabel or GPT disklabel for PV, I prefer now to use directly LVM on the main block device. There is no reason to use 2 disklabels, unless you have a very specific use case (like disk with boot sector and boot partition).

The advantage of having LVM directly are:

  • simplicity - you do not need to use 2 sets of tools
  • flexibility - you can use pvmove to move the data from one disk volume to another without downtime, you can use snapshot and thin provisioning
  • you do not need to run partprobe or kpartx to tell the kernel that you created/resized/deleted a volume. And partprobe/kpartx could fail if partitions are in use and you might need to reboot
  • maybe better performance, compared to using LVM on top of MS-DOS or GPT disklables
  • avoids potential misalignment if the partition created with fdisk is not aligned with the extents on the underlying volume (e.g. RAID array)
Mircea Vutcovici
  • 16,706
  • 4
  • 52
  • 80
  • 5
    Not sure why everyone wants that partition - but answer here go in the direction of "why not". This answer is better - you don't need a partition if you're going to use the whole disk. Having a partition can also make resizing/extending disks a lot more painful. – bryn Nov 27 '18 at 10:58
  • many unix system administrator bring this logic to linux, I remember veritas volume manager that works with public and private, in Linux this doesn' has any sense – c4f4t0r Jan 22 '19 at 02:57
6

If you create a PV directly on a virtual storage device inside a KVM guest, then you will notice that the logical volumes from the guest are visible on the hypervisor. This can make things quite confusing if you use the same logical volume and volume group names across multiple guests. You may also get some warnings on the hypervisor saying that it can't find a device.

For example, I have recreated this problem on my test hypervisor:

[root@testhost ~]# vgs
  Couldn't find device with uuid dCaylp-1kvL-syiF-A2bW-NTPP-Ehlb-gtfxZz.
  VG          #PV #LV #SN Attr   VSize   VFree  
  vg_main       2   2   0 wz-pn-  19.25g 768.00m
  vg_main       2   2   0 wz-pn-  19.25g 768.00m
  vg_testhost   1   8   0 wz--n- 237.98g 120.15g

Here you can see 2 volume groups with the same name, both from guests which shouldn't really appear on the hypervisor.

For this reason, I would advise that you use parted or fdisk to create a KVM partition on there first (as shown in the previous answer by 3dinfluence), before creating a PV and adding it to a volume group. That way, the guest logical volumes remain hidden from the hypervisor.

Paul Maunders
  • 61
  • 1
  • 3
  • 4
    This can be avoided if you use `filter` in /etc/lvm/lvm.conf to filter out all block devices used directly by your VMs. – Mircea Vutcovici Feb 09 '17 at 01:20
  • 1
    The disks are always present on the host anyway - the partitions are just not mapped. `kpartx -a` would do that for you. The hypervisor has access to all guest disks, but volume groups should not be activated. – bryn Nov 27 '18 at 10:48
6

According to LVM guide from RedHat, section 4.2.1 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/logical_volume_manager_administration/physvol_admin

They said there is no need to have the partition table, they even suggest us to destroy it if we use the whole disk for VG (Volume Group) unless we only intend to include only parts of it (partition).

Pisacha Srinuan
  • 61
  • 1
  • 1
4

One downside is that it is not be possible to hot-add space to a PV inside a partition table. This is not an issue if you use the entire block device for the PV.

user217432
  • 51
  • 1
  • 1
    As of 2018 you can add space on a PV inside a partition table. I made this script which can generate the commands required to do that: https://github.com/mircea-vutcovici/scripts/blob/master/vol_resize.sh – Mircea Vutcovici May 17 '18 at 13:28
0

Does LVM need a partition table ?

  • No it doesn't require it (see other answer by Pisacha Srinuan for the link).

Is this a bad idea ?

  • In some situations, yes, in other, no.

Explanations (to complete the good answers above that correspond to different use cases):

Nowadays, Linux and LVM are used so widely that many different use cases share these same technologies, but they have very different operational constraints and requirements.

The most common example is: is your LVM disk a storage system A) used by hypervisors to store many virtual machines image files?

Or is it B) for a single, probably virtual, machine ?

In the first case A), you would need to split your LVM disk into smaller portions to reduce the granularity of the volumes space management, and also for your failure recovery risk management. You may also want to use more features of LVM, including RAID redundancy, thin pools, etc... This is best done by splitting your huge disk into partitions of smaller sizes, each of them becoming an LVM PV in your volume group. This way, in case of incident, you may reduce the probability of the incident (with redundancy). And its impact and/or resolution time if you need to resort to physical disk recovery of smaller partitions. How many exactly will depend on your risk tolerance, your service commitments, your availability expectations and design, etc ... A rule of thumb is that reducing the impact and recovery time by a factor of 10 is always welcome, and 10 is still a manageable number for partitions.

Another reason is LVM Metadata stored on each PV. LVM does store its metadata in several locations on each PV, according to Red Hat LVM docs. If you use a raw device instead of a partition, the creation of a partition table at some time, like during a data recovery attempt, would overlap with and damage your LVM metadata and render you data unusable, or much more difficult to recover. This data loss would not happen on a disk with a pre-existing partition table.

In the case B), a single system might benefit from the simplicity of a PV without partition table, as the recovery process might be ensured by the hypervisor layer backup system, if it is a virtual server. But you need to make sure of it before to decide to go for this simplicity.

kitatech
  • 1
  • 2