When it comes to LVM, I'm confused on when I use either of these commands:

or

Do I run pvresize when there are no partitions? For example, here is a very basic system:

I have three partitions here and say I want to grow /dev/sda3 from 20 GB to 40 GB. There is no reason to increase Swap or Boot. I get confused if I am to use pvresize or pvcreate.

If I use pvresize, I'm basically using that command against /dev/sda, correct? Or do I run it against a file system that doesn't have any partitions?

If there are partitions, what command then do I want to use?

I feel like that if I use pvresize, I'm going against the whole partition of /dev/sda, when all I want to do is resize the /dev/sda3

I hope this makes sense on what I'm asking.

You don't appear to be using LVM at all, so neither pvcreate nor pvresize is appropriate. Assuming that you have unallocated space following partition 3 on the disk, you need to use conventional partitioning tools to enlarge partition 3. Then, run "resize2fs /dev/sda3" to enlarge the filesystem to make use of the enlarged partition.

What I wrote up was just a demo, not a real systems.

Yes you are correct, I could run the following commands:

or
If there is extra space then allocate that space via lvcreate and home free.

However what if there isn't extra space. If this is a VM, using the hypervisor, I would add the space there, however I'm still not sure what command to use next, either the pvcreate or pvresize?

You can run pvresize only if the device in question has already been formatted as a PV. You use pvcreate to make a PV out of a non-PV device.

pvresize is only useful if the underlying device's size has changed, for example as a result of resizing a disk array LUN.

From what you are saying, it seems you misunderstand how LVM works. Here is the workflow in a very much simplified nutshell. I urge you to read up on this, for example with the LVM Howto on tldp.org.

You start with a disk, a partition, a LUN etc. Let''s call it /dev/sdx1.
Now, when the size of /dev/sdx1 changes, a pvresize is appropriate.

Ok so if the size of one of the partitions is to change, then use the command pvresize.

If this is the case, does one have to use fdisk to delete the partition, create the partitions again and make sure the new cylinder is larger then the previous?

If so, how does this affect the data that lives on that partition? Is it destroyed when using fdisk?

Only if the partition is an LVM physical volume. Which doesn't seem to be the case here.

When the size of a partition changes, one doesn't have to use fdisk. If the partition is a physical volume, use pvresize. However, judging from the original post, your system doesn't use LVM, thus pvresize doesn't apply.

In order to change the size of a partition, you can use fdisk roughly in the manner you described, but there are better tools, for example the parted family.

The example I created is just that, and example. Something off of the top of my head. I've been thinking about this topic the last few days.

Let me lab something up as a better example.

You seem to have a lot of misconceptions about how these structures are layered. The normal setup is this:

1. You use a partitioning tool to set up partitions on one or more disks.
2. On those partitions you wish to use with LVM, you run pvcreate to write a PV header there, allowing LVM to recognize them a physical volumes.
3. You use vgcreate to collect your PVs into volume groups.
4. Within each VG, you use lvcreate to assign space to logical volumes.
5. You format each LV as a filesystem, swap space, or whatever.

Some of these layers can be omitted:

• It is possible, though not generally recommended, to skip the partitioning step and create an LVM PV directly on the unpartitioned disk drive. Why is this not recommended? There are several places where the system expects that physical drives will normally have a partition table, and might get confused or show the drive as being empty if no partition table is present.
• You can, of course, skip the LVM steps entirely and format each partition as a filesystem. That's what you do when you are not using LVM.
• For that matter, you can skip all of the intervening steps and format a filesystem directly on the unpartitioned drive. The same caution as above applies.

When you are using LVM, in many cases you can skip the pvcreate step and go straight to vgcreate. When you run vgcreate on a device not previously set up by pvcreate, the device gets set up with default PV parameters. That layer still exists -- you just didn't have to do it explicitly.

LVM makes it easy to add space by dropping in a new drive or creating a new partition from unallocated space, initializing that space as a new PV, adding that PV to a volume group, and then expanding existing LVs and their filesystems in that enlarged VG. The downside is that it gets harder to shrink elements or rearrange existing space because you have to be aware of all the layers when doing that.

I understand the structure:

lvs
vgs
pvs


I'm still not certain which commands to use where. pvresize VS vgextend Vs lvextend.

I understand that if there is extra space under a VolGroup, then vgextend will grab that space and then we can allocate it to lvextend. And then run resize2fs.

Where does pvresize come into play?

Some of the Redhat documentation is using fdisk to say delete /dev/sda3 and then recreate it with fdisk again. Then pvresize /dev/sda3.

https://access.redhat.com/solutions/100623


Is this the correct way to go about it?

pvresize to tell LVM that the size of a physical volume has changed.
vgextend to add a physical volume to a volume group.
lvextend to change the size of a logical volume.
When LVM isn't aware that the size of the physical volume has changed.

If you want to change the size of a partition, then you can use the Red Hat trick.

Personally, I think it's better to use parted instead of fdisk. It has a command resizepart. I also thought one could move and copy partitions around with parted, but that functionality seems to have been removed (http://www.gnu.org/software/parted/m...d-explanations).

Make that whenever the size of the physical volume has changed. Otherwise, it's just like changing the size of a partition without resizing the filesystem within it. You either end up with unusable space (if you enlarged the partition) or I/O errors when the filesystem no longer fits in a partition you made smaller.

Ok, let us revisit this because I just had another issue come up and I think I finally understand it.

So I have a RHEL VM where there is a partition that was running out of space. When I used fdisk -l, to view the partition there were no partitions. I guess I still don't understand, we have Oracle living under this partition, /dev/sdd, yet there isn't a partition number like /dev/sdd1. I guess I don't understand this, why isn't there a partition number?

So I went ahead and ran the following:

Ok, when using pvdisplay -m, I didn't see the Volume Group or the Logical Volume that this partition lived under. So now I wasn't sure what to do, however if I looked under /etc/lvm, the Volume Group and Logical Volume showed up under there.

So...doing some more research with Red Hat. I learned that I don't need to use pvcreate in this case.

- Because there is no partitions, all I have to do grow the disk from VMWare

- Scan the disk with one of the following commands on this partition, in this case its /dev/sdd

- Then issue the following command: pvresize /dev/sdd

- Then lvextend -l+100% VolGroup03-LogVol00

- And finally resize2fs /dev/mapper/VolGroup03-LogVol00

That's it.


So...in the other case...If there is a partition say on /dev/sdd1, then I would have to do the following:

- add space from VMWare

- use fdisk/parted and create a new partition, /dev/sdd2

- scan the disk so fdisk/parted picks up the new space

- then use vgextend (the Volume goes here) /dev/sdd2

- then use lvextend -L +100% (Volume goes here) (Logical Volume goes here)

- mount the partition

- mkfs -t (file system here) /partition/to/grow/here


Hopefully my thinking is correct here.

thanks

I believe you need pv first.

as it goes pv > vg > lv

Not really. Quote from the vgextend manpage:

If PhysicalDevicePath was not previously configured for LVM with pvcreate(8), the device will be initialized with the same default values used with pvcreate(8). If non-default pvcreate(8) values are desired, they may be given on the commandline with the same options as pvcreate(8).

it is a new device, in this case you do need pvcreate.

"sdd"