24

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!

Improve this question
31

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?

Improve this answer
5
  • 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
  • 10
    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
  • 2
    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
16

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
Improve this answer
3
  • 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 2:52
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.

Improve this answer
2
  • 2
    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 9 '17 at 1:20
  • 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
5

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
Improve this answer
2
  • 3
    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 2:57
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.

Improve this answer
1
4

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).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.