Joe -
I think you are covering what I need, but since you are describing
a couple of options I will describe my system in more detail. My goal
here is that I want to know precisely what I am doing, and what the
response of the system should be before I issue a command.
Your reference to a device rescan caught my attention and I think
is the step I am missing in my knowledge. OMSA shows I have one Virtual
Disk(00) with RAID 5, a size of 836.62 GB, and device name of /dev/sda.
Yet the host system shows:
[root@earth ~]# fdisk -l /dev/sda
Disk /dev/sda: 598.9 GB, 598879502336 bytes
255 heads, 63 sectors/track, 72809 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b2ab0
Device Boot Start End Blocks Id System
/dev/sda1 * 1 64 512000 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 64 72810 584330240 8e Linux LVM
So the layout of my virtual drive is a boot partition, then everything
else is a single LVM physical volume. The above fdisk output matches
what I see in GParted. So I believe that ultimately I need to do a
pvresize in order to have unallocated space in my volume group that I
can assign to whatever virtual machine partition I need. Once I have
the unallocated space in my volume group I know what steps to complete
after that.
But I believe right now that pvresize won't do anything because fdisk
does not recognize the additional drive space that I have added to the
virtual disk. That is why I believe the rescan is what I need.
So generically,
1. rescan the scsi bus
2. pvresize
3. then I should see the unallocated space in my volume group ?
Does this sound about right?
Go ahead and cc me directly as I forgot to mention that I only get the
daily digest of this list.
Thanks.
Jeff
On 3/22/2017 7:16 PM, Joe Gooch wrote:
> I'd imagine you have some partitions there :)
>
> Maybe sda1 for boot, sda2 swap, sda3 LVM or some such thing.
>
> Should the drives need to be rescanned this will do it:
> for i in /sys/class/scsi_device/*/device/rescan; do echo "1" > $i; done
>
> Depends on whether dmesg |grep sda is returning the right drive space -
> giving that fdisk is, I'm guessing it already picked up the change from the
> underlying hardware.
>
>
>
> If you try to extend the partition you'll need to reboot for it to take
> effect.(after making appropriate changes) If you're extending a filesystem
> on a partition, that's what you'll want to do. (use fdisk, gdisk, parted,
> etc to extend the partition - which in the case of fdisk means "WRITE
> EVERYTHING DOWN PRECISELY" then "DELETE the partition and pray I wrote the
> info PRECISELY" and then create a replacement partition with the PRECISE
> start position and an end position further up the drive. Or you could use
> something more advanced that can resize and move partitions around more
> safely, with a GUI, etc. After a reboot, assuming everything lined up you
> can extend the filesystem.
>
> If all that sounds dangerous, it isn't as dangerous as it sounds, but it's
> tedious. Which is why hopefully you used LVM.
>
> With LVM, I'd recommend instead of trying to extend the partition, just
> create a new one. Create a new partition with the additional space, make it
> also a LVM partition type, save. Since it's a new partition, it should fire
> up... If not partprobe or kpartx can liven it up. (Since it's a new
> partition, no existing filesystem mount will have it locked) Then you can
> pvcreate /dev/sda4 or whatever it ended up being, and then vgextend
> YourVGName /dev/sda4, and then you can lvextend -L +50G
> YourVGName/YourLVName, and then you can resize2fs or mount -o remount,resize,
> as appropriate for your filesystem.
>
> If you decide to extend the LVM partition instead, follow the previous
> instructions, then pvresize /dev/sda3 (for example), then lvextend, then
> resize2fs.
>
> As an aside this is one of the reasons why wherever possible I pvcreate on
> whole disks, not partitions. (I.e. pvcreate /dev/sda) For physical servers
> that ends up being a RAID1 system mirror with partitions as normal, and a
> second VD (R5 or R6 or whatever) that can be used for bulk storage. For VMs,
> it's a boot drive VMDK, a swap drive vmdk, and a LVM vmdk. /dev/sda1 gets
> the boot volume, mkswap /dev/sdb, pvcreate /dev/sdc.
>
> Then all changes that might need to be made later can be made live. Rescan
> the bus, physical drive object increases in size, pvresize and you're good to
> go.
>
>
>
> --
>
> Joe
>
>
>
>
>
>
>
