Tech

Using large vDisks in OnApp – Part 2: resizing an existing vDisk > 2TB

This is the second technical blog in a series about using large vDisks on OnApp KVM compute resources. In the first blog, I described how to add a new vDisk to a Linux virtual server, and then resize it beyond 2TB.

This time, I’ll show you how to convert an existing vDisk to GPT, so you can resize it beyond 2TB without data loss.

 

 

 

How to resize an existing vDisk beyond 2TB

* Note – the following procedure is applicable only to Linux-based VSs running on KVM compute nodes. ALSO NOTE: resizing an existing vDisk does have the *potential* to cause data loss, so you MUST ensure that you have a backup and run fsck before proceeding further.

 

Converting from msdos to GPT requires having some free space in the end of the virtual disk partition. All we have to do is to shrink the partition from the rightmost side a little bit (about 3Mb but could be less) and the result should be following:

 

You can boot this virtual server from a gparted ISO for vDisk resizing, available at https://gparted.org/download.php. Or, if you are sure you have free 3MB in the end of the partition, you can proceed to the following steps that don’t require booting from ISO:

 

1. Connect to the VS via SSH or VNC console and locate the vDisk you want to resize for more than 2TB. In this example, it’s a 1TB disk. It has an msdos partition table and about 70% space used:

root@onappgpttest:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
fd0 2:0 1 1.4M 0 disk
vda 253:0 0 5G 0 disk
└─vda1 253:1 0 5G 0 part /
vdb 253:16 0 1G 0 disk [SWAP]
vdc 253:32 0 1000G 0 disk
└─vdc1 253:33 0 1000G 0 part /mnt/1
root@onappgpttest:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 224M 0 224M 0% /dev
tmpfs 49M 1.8M 47M 4% /run
/dev/vda1 4.8G 1.4G 3.2G 30% /
tmpfs 241M 0 241M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 241M 0 241M 0% /sys/fs/cgroup
tmpfs 49M 0 49M 0% /run/user/0
/dev/vdc1 985G 626G 309G 67% /mnt/1

* Note. You have to be sure that there is about 3 MB of free space in the end of the partition!

 

2. Unmount the destination vDisk.

root@onappgpttest:~# umount /mnt/1/

 

3. The partition usually starts in sector 1024. Please check its sector before proceeding further.

root@onappgpttest:~# parted -s /dev/vdc unit s print
Model: Virtio Block Device (virtblk)
Disk /dev/vdc: 2097152000s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1024s 2097151999s 2097150976s primary ext3 boot

 

4. Now we’re going to convert the vDisk from msdos to GPT – but before you do that, install the gdisk utility. It allows you to convert without data loss.

Ubuntu/Debian:

apt install gdisk

RedHat/Centos:

yum install gdisk

 

5. Delete the existing partition.

root@onappgpttest:~# parted -s /dev/vdc rm 1

 

6. Convert vDisk from msdos to GPT.

root@onappgpttest:~# sgdisk -g /dev/vdc

When the operation has been completed successfully, the vDisk will have been converted to GPT. It doesn’t matter whether you use OnApp’s Integrated Storage or an LVM-based datastore, since the procedure involves only the resize of a logical volume.

 

7. Next, we are going to increase the vDisk capacity via the OnApp GUI to the size you require (larger than 2TB).

*Note. There should be no partition on the vDisk before resizing in GUI, otherwise, the transaction will fail.

The transaction will run successfully if there is no msdos partition. The transaction also requires a reboot of the VS.

 

8. Connect to the VS via SSH or VNC console again, to check if the vDisk size is the one you need:

root@onappgpttest:~# sgdisk -p /dev/vdc
Disk /dev/vdc: 5242880000 sectors, 2.4 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): E6D753FD-E226-4270-8123-3A994747208B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 2097151966
Partitions will be aligned on 2048-sector boundaries
Total free space is 2097151933 sectors (1000.0 GiB)
Number Start (sector) End (sector) Size Code Name

 

9. Next, move the second header to the end of the extended virtual disk – which allows you to use the whole increased space for partition.

* Note. GPT writes its partition table to both ends of the disk, unlike MBR, which only uses the beginning.

root@onappgpttest:~# sgdisk -e /dev/vdc

Now, a partition can be created using all of the vDisk size:

root@onappgpttest:~# sgdisk -p /dev/vdc
Disk /dev/vdc: 5242880000 sectors, 2.4 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): E6D753FD-E226-4270-8123-3A994747208B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5242879966
Partitions will be aligned on 2048-sector boundaries
Total free space is 5242879933 sectors (2.4 TiB)
Number Start (sector) End (sector) Size Code Name

 

10. Create the new partition from sector 1024 to the end of vDisk.

root@onappgpttest:~# sgdisk --set-alignment=1024 -n 1:1024:$ENDSECTOR /dev/vdc

 

11. Run e2fsck and resize2fs:

root@onappgpttest:~# e2fsck -f /dev/vdc1
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vdc1: 12/65536000 files (0.0% non-contiguous), 168164440/262143872 blocks
root@onappgpttest:~# resize2fs /dev/vdc1
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on /dev/vdc1 to 655359867 (4k) blocks.
The filesystem on /dev/vdc1 is now 655359867 (4k) blocks long.

 

Now the vDisk has been resized and is ready to use. I hope the procedure is helpful for resizing your existing drives!

* Remember! This procedure is only applicable to KVM compute nodes/Linux VSs. Also note: you won’t be able to decrease the size of the virtual disk with the increased capacity. However, you can increase the size of such a vDisk again wihout data loss, using the same procedure, but skipping the fourth step.

If you need any help, just contact OnApp support. Thanks!