Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?


share|improve this question

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?

share|improve this answer
+1 for the scenario. All too likely in real life. – Hennes Oct 16 '12 at 17:21
+1 for being insightful. – Alexander Janssen Oct 16 '12 at 18:59
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
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

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
share|improve this answer
"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
No longer true. mkpart primary 1M 100% works and leaves File system field blank. – stark Jan 13 '15 at 15:21

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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