lvm on whole disk for online resizing supported ?

Latest response

Hello all,

We use Redhat 6.5 VMs on Vmare Vsphere.
I put all my lvm on a whole disk ( pvcreate /dev/sdb for example)

With this kind of setup, i can resize my VMDK and the PV => VG => LV online, no need to add partition or reboot.

Is this setup supported by Redhat ? (LVM whole disk configuration)
Is a KB that prove that ?

Thank you

RG
Log in to join the conversation

Responses

ir. Jan Gerrit Kootstra's picture Guru 6222 points
18 June 2015 8:31 AM

Hi Romain,

Supported features question of this kind are not only related to Red Hat, but also VMware. VMware stated in the past that only well aligned disk partitions were supported due to possible performance issues.

So you have to ask this question both via a Red Hat support case, and via VMware support. As community members we can say what we know, but support may have changed her policies due to know performance issues.

Kind regards,

Jan Gerrit Kootstra

RG Community Member 36 points
18 June 2015 8:56 AM

Thank you Jan,

So i need to open a Redhat support case to know if putting LVM on whole disk are supported ?

Best regards

thomas.jones2@dodiis.mil's picture Guru 6435 points
18 June 2015 9:17 PM

Aside from the general ickiness of placing your LVM on an uninitilized/unpartitioned disk (clearly, you've never had someone come along and say, "oh, look: an unpartitioned disk. It must be available for use!" and clobber it), the general recommendations for LVM on VMware (in particular) is that you use aligned disks. You'd be better served doing something like:

parted -s /dev/sdb mklabel gpt mkpart primary ext4 2048s 100% set 1 lvm on
vgcreate VolumeGroupName /dev/sdb1
lvcreate -l 100%PVS -n VolumeName VolumeGroupName /dev/sdb1
mkfs -t FSTYPE /dev/VolumeGroupName/VolumeName

Depending on how many VMs you've got running and how hard you're pushing your storage, failure to properly align your VM-level storage-objects to the underlying storage-layers can prematurely degrade the performance of your storage subsystems.

And with respect to online resizing, whether you do it direct to the whole-dev or on a partition, you can do a no-reboot resize for any volume hosting unmountable filesystems.

RG Community Member 36 points
19 June 2015 7:16 AM

Well...the "Oh look an unpartitioned disk" thing have no place where i work.

Yes you can still online resize but in a ugly way (adding more partition...) or playing with fdisk...and partprobe...no thanks.

Putting a LVM on a whole disk and online resizing is very smooth.

Example :

  • Resize your VMDK (increase of course)
  • install sg3_utils package and run "rescan-scsi-bus.sh"
  • check with fdisk the new size
  • run pvresize on you disk
  • pvs to check the new size
  • make a online resizing #lvextend --resizefs -l+100%FREE /dev/mapper/your_lv

And it's done.

Don't take it personal...but i'm fed up with the same ol same ol speech about partition on LVM...

Here a very good quote from a forum :

"

Creating physical volumes on partitions that take up 100% of the disk is almost never the right thing to do. I say "almost" just because I take the attitude that just because I can't think of a reason to do something, that doesn't mean there's no reason to do it. That said, I can't think of a single reason to put partitions on a disk at 100% of the space if it's going to be LVM.

You're getting no discernible benefit in exchange for getting some of the rigidity of partitioning back. If these are SAN-backed physical volumes, and you do that, there are only two ways to expand the storage space in the volume group:

Present a new larger LUN, add it to the volume group, pvmove off the LUN you inexplicably partitioned, remove it from the volume group, and tell the SAN people to unpresent it. Which might work, and can be done online (with a performance hit, and assuming they're enough SAN space in your storage pool on the SAN side to hold these two LUN's simultaneously) but it's doable.
The only other way is to go back to dealing with partitions, which is part of the reason people like well-designed volume management schemes (like with btrfs, lvm, zfs, etc). You can edit the physical volume's partition table and hope partprobe let's you read the new sizes in, but that only works about 1 time out of 2 from my personal experience and it requires you to unmount the filesystem (i.e forces you to go offline another reason people like volume managers).

If you do a whole disk the SAN admin can expand the LUN out for you, you re-scan the SCSI bus, it picks up the new size of the LUN, then you do a pvresize to expand the physical volume out. All without taking any filesystems offline.

Going off the MBR bit, you don't typically take PV's from one system and present them to another in an enterprise environment. Even if you did, if it's LVM you're going to want the OS to which you're going to be presenting the LUN to support LVM. Otherwise what's the point of presenting it to them? If it does then you get to see all the physical volume information, volume group information and logical volumes (assuming this is the only PV in the volume group). So it self-documents that way.

Basically: partitioning a whole disk to 100% is like demanding that the waiter who brought you an apple pie also bring you a knife as well. When he does you throw the knife to the side and just bury your face in the pie. Meaning: it doesn't make sense to insist on a tool to portion something out into smaller pieces if you're just going to use it all in one go anyways.
"

thomas.jones2@dodiis.mil's picture Guru 6435 points
19 June 2015 12:53 PM

For whatever reason, our security folks have deemed that the sg3_utils package is not to be installed on production hosts. Doesn't really matter, since all you really need to do is echo "- - -" > /sys/class/scsi_host/hostN/scan to get the same effects.

Unfortunately, we've found that simply rescanning the bus and/or trying to use fdisk hasn't been 100% reliable in getting the kernel to reload updated LUN size or disk-geometry information (likely more an issue in EL5 than EL6). We've generally found that blockdev is the more reliable method for forcing the kernel to update its disk-geometry information. Being a lower-level utility, blockdev requires the device-node to be offline so it can issue its ioctls (if your device node isn't offline, blockdev is nice enough to tell you that it can't update the device geometry - some tools simply fail silently).

fdisk also doesn't handle GPTs terribly well - which means it's frequently not usable against our larger chunks of storage, any way. Given the multi-vendor nature of our environment's storage (inclusive of host-level storage-management), the mix of physical and virtual hosting, mix of older and newer systems (read: we still have RHEL 5 floating around, thus, for the sake of consistency, a non-trivial number of our procedures are being held-over till the last EL5 system leaves our datacenters) and the realities of distributed teams of SAs of radically-varying skill-levels, we do things to help "safe" the environment (that means choosing "least common denominator" management options and blindingly-obvious labeling where possible).

Our environment is also highly-automated: we use lots of automated CM and tools like KickStart to build systems. fdisk doesn't lend itself as easily to automated provisioning and/or CM. If you're using KickStart, any where, getting used to parted means you're already well-prepared to author and maintain KickStart profiles that do dynamic storage layout well.

Not that partprobe was previously part of this thread, but since it was mentioned in that quote, it has deficiencies as well. We've found that partprobe is proven less reliable than tools like kpartx (and both are less reliable absent use of tools like blockdev). kpartx has generally proven to be more useful to us in our remaining physical hosts that leverage multipathing.

At any rate, we've generally deprecated fdisk in favor of parted. for reasons listed above,. Once you're already standardized on running parted, doing a parted -s /dev/sdX mklabel gpt mkpart primary ext4 2048s 100% set 1 lvm on on a properly-reread device ensures that the disk-structures are both properly-aligned (which, given how hard our virtualization environments push our storage, is kinda critical) and saves the hassles associated with trying to use fdisk to change your disk's partitioning-scheme. pvresize has not generally seemed to care whether it's reading an expanded /dev/sdb or an expanded /dev/sdb1.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.