So, there has been few tricky issues going on with expanding VDP storage drives. This section would talk about specifically about OS Kernel not picking up the partition extents.
A brief intro about what's going on here. So, you know in vSphere Data Protection 6.x onward the dedup storage drives can be expanded. If your backup data drives are running out of space and you do not wish to delete restore points, then this feature allows you to extend your data partitions. In this case, we will login into the https://vdp-ip:8543/vdp-configure page, go to the Storage tab and select the Expand Storage option. The wizard successfully expands the existing partitions. Post this, if you run df -h from the SSH of the VDP, it should pick up the expanded information. In this case, either none of the partitions are expanded or few of them report inconsistent information.
So, in my case, I had a 512 GB of VDP deployment, which by default deploys 3 drives of ~256 GB each.
Post this, I expanded the storage to 1 TB. Which would ideally have 3 drives of ~512 GB each. In my case the expansion in wizard completed successfully, however, the data drives were inconsistent when viewed from command line. In the GUI, Edit Settings of the VM, the correct information was displayed.
When I ran df -h, the below was seen:
root@vdp58:~/#: df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 32G 5.8G 25G 20% /
udev 1.9G 152K 1.9G 1% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/sda1 128M 37M 85M 31% /boot
/dev/sda7 1.5G 167M 1.3G 12% /var
/dev/sda9 138G 7.2G 124G 6% /space
/dev/sdb1 256G 2.4G 254G 1% /data01
/dev/sdc1 512G 334M 512G 1% /data02
/dev/sdd1 512G 286M 512G 1% /data03
The sdb1 was not expanded to 512 GB whereas the data partitions sdc1 and sdd1 were successfully extended.
If I run fdisk -l then I see the partitions have been extended successfully for all the 3 data0? mounts with the updated space.
**If you run the fdisk -l command and do not see the partitions updated, then raise a case with VMware**
255 heads, 63 sectors/track, 66837 cylinders, total 1073741824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdb1 1 1073736404 536868202 83 Linux
Disk /dev/sdc: 549.8 GB, 549755813888 bytes
255 heads, 63 sectors/track, 66837 cylinders, total 1073741824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdc1 1 1073736404 536868202 83 Linux
Disk /dev/sdd: 549.8 GB, 549755813888 bytes
255 heads, 63 sectors/track, 66837 cylinders, total 1073741824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sdd1 1 1073736404 536868202 83 Linux
If this is the case, run partprobe command. This makes the SUSE Kernel aware of the partition table changes. Post this, run a df -h to verify if the data drives are now updated with the correct size. If yes, then stop here. If not, then proceed further.
**Make sure you do this with a help of VMware engineer if this is a production environment**
If the partprobe does not work, then we will have to grow the xfs volume. To do this:
1. Power down the VDP appliance gracefully
2. Change the data drives from Independent Persistent to Dependent
3. Take a snapshot of the VDP appliance
4. Power On the VDP appliance
5. Once the appliance is booted successfully, stop all the services using the command:
# dpnctl stop
# xfs_growfs <mount point>
# xfs_growfs /dev/sdb1
root@vdp58:~/#: xfs_growfs /dev/sdb1
meta-data=/dev/sdb1 isize=256 agcount=4, agsize=16776881 blks
= sectsz=512 attr=2
data = bsize=4096 blocks=67107521, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0
log =internal bsize=4096 blocks=32767, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 67107521 to 134217050
Run df -h and verify if the partitions are now updated.
root@vdp58:~/#: df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 32G 5.8G 25G 20% /
udev 1.9G 148K 1.9G 1% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/sda1 128M 37M 85M 31% /boot
/dev/sda7 1.5G 167M 1.3G 12% /var
/dev/sda9 138G 7.1G 124G 6% /space
/dev/sdb1 512G 2.4G 510G 1% /data01
/dev/sdc1 512G 334M 512G 1% /data02
/dev/sdd1 512G 286M 512G 1% /data03
If yes, then stop here.
If not, then raise a support with VMware, as this would go for engineering fix.
If not, then raise a support with VMware, as this would go for engineering fix.
Hope this helps.
0 comments:
Post a Comment