LVM disk extend after P2V to VMWARE

Latest response

We have recently P2V'd a physical RHEL 5.8 system to VMware.

FDISK shows the resized disk
Disk /dev/sdb: 214.7 GB, 214748364800 bytes
68 heads, 4 sectors/track, 1542023 cylinders
Units = cylinders of 272 * 512 = 139264 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 948737 129028096 8e Linux LVM

But I am unable to resize...
Failed to read physical volume "/dev/sdb"
0 physical volume(s) resized / 0 physical volume(s) not resized

Was wondering if anyone has run into this issue.
Thanks.

AC
Log in to join the conversation

Responses

james.radtke@siriusxm.com's picture Guru 6863 points
14 January 2014 3:30 PM

Can you provide more details of the actual steps (and commands)? I.e. did you run parted, partprobe, kpartx, blockdev, pvresize, etc..

I'm sure we can get this figured out with those details.

Also, run the following:

vgs && pvs && lvs
parted /dev/sdb print

Thanks!

AC Newbie 15 points
14 January 2014 3:47 PM

Thanks James. Here is the procedure we use to extend disks for virtual rhel.

  1. Resize the VMware disk.
  2. Either reboot of rescan the disk within the OS..in this case we rebooted.
  3. Issue "pvresize /dev/sdb"
    Steps 4 & 5 would be an lvextend followed bye a resize2fs on the volume. What is bizarre is the disk does show as extended in fdisk, output below. I had run into this in the past with unsupported methods of VMware converter but never pursued as it was unsupported, now it is.

isk /dev/sdb: 214.7 GB, 214748364800 bytes
68 heads, 4 sectors/track, 1542023 cylinders
Units = cylinders of 272 * 512 = 139264 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 948737 129028096 8e Linux LVM

vgs
VG #PV #LV #SN Attr VSize VFree
VolGroup00 1 2 0 wz--n- 53.00G 0
VolGroup01q 1 4 0 wz--n- 123.05G 0
pvs
PV VG Fmt Attr PSize PFree
/dev/sdb1 VolGroup01q lvm2 a-- 123.05G 0
/dev/sdc1 VolGroup00 lvm2 a-- 53.00G 0
lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
LogVol00 VolGroup00 -wi-ao 50.00G
LogVol01 VolGroup00 -wi-ao 3.00G
LogVol01 VolGroup01q -wi-ao 19.53G
LogVol02 VolGroup01q -wi-ao 5.86G
LogVol03 VolGroup01q -wi-ao 48.83G
LogVol04 VolGroup01q -wi-ao 48.83G
parted /dev/sdb print

Model: VMware Virtual disk (scsi)
Disk /dev/sdb: 215GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number Start End Size Type File system Flags
1 65.5kB 132GB 132GB primary lvm

thomas.jones2@dodiis.mil's picture Guru 6435 points
18 January 2014 12:48 AM

I'm not seeing an indication that you extended the partition on /dev/sdb? Normally, when you grow a device, you do:

  1. Grow vDisk/LUN
  2. Rescan device for geometry changes (fails if device is open/in use)
    3a. If wishing to continue to only have one partition, delete existing partition and re-create to match new vDisk/LUN size
    3b. Otherwise, add another partition to disk that extends to the end.
    4a. Do a pvscan/vgscan so that LVM sees the new partition size
    4b. Do a vgextend onto the new partition
  3. Perform lvextend
  4. Perform your fs-resize operation.
james.radtke@siriusxm.com's picture Guru 6863 points
18 January 2014 1:46 AM

Everything I find recommends creating a new partition with the new portion of disk that was found, then growing the VG and extending the LV.

I would try:

blockdev --rereadpt /dev/sdb
partprobe /dev/sdb
blockdev --report
parted /dev/sdb print

Then, I would also look at this doc, section 7:
http://www.thegeekstuff.com/2011/09/parted-command-examples/
and rerun the commands above to rescan and update the partition table, etc..

I am going to spin up a machine to test this and I will update this response with the steps. If you happen to test this before I, can you please update the thread?
Good luck ;-)

thomas.jones2@dodiis.mil's picture Guru 6435 points
21 January 2014 4:33 AM

Doing things that way limits the number of times you can expand your vDisk or LUN. Redoing the disk's single partition means you can extend it an arbitrary number of times. You also don't have to worry about whether you remembered to properly align each of the subsequent partitions (so long as the partition-to-be-extended was properly aligned when first set up)

AC Newbie 15 points
14 January 2014 8:02 PM

Our existing procedure doesn't work because the P2V process creates a partition instead of dumping the entire disk LVM. We would need to extend the partition for vgextend which we don't want to do.
Thanks.

ir. Jan Gerrit Kootstra's picture Guru 6222 points
18 January 2014 4:38 AM

Anthony,

Which method do you use for P2V?
That might have caused the disk partitioning.

Kind regards,

Jan Gerrit Kootstra

Close

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