OVH Community

Welcome to your community space. Ask questions, search for information, post content, and interact with other OVH Community members.

Upgrading your VPS - need to extend your disk? The Easy way!


#1

If you’ve upgraded from SSD VPS 1 to 2 to 3 then the instructions are a bit Draconian to get your extra disk space added on (memory & CPU will be automatic).

This was tried and tested on a working CentOS 7 cPanel server from VPS SSD 1 to 2 and no issues.

So rather than reboot to recovery and not have LVM2 available for lvextend, nor be able to install it or anything else and I’ve never been happy with the Russian Roulette of deleting and recreating the root partition I found this works.

3 simple steps while the VPS is still running with no dodgy deleting of partitions, although give it a reboot when you can.

You can use terminal from WHM for this if you like or any SSH client and assuming the basic VPS SSD setup for 1 disk issue these commands;
---------------------------------------------------------------------------
yum install cloud-utils

growpart /dev/sda 1 (notice space before the 1 and this will allocate all available free space)

resize2fs /dev/sda1
--------------------------------------------------------------------------

And your done!

I wouldn’t say it was a bad move to reboot to rescue mode and do a system file check but I found no issues.

Hope this helps someone out that gets a bit frustrated at rescue boots having nothing like the toolset you’d like :slight_smile: or the option to boot to a live OS to carry out maint work.


#2

Thank you for posting this, you certainly saved me some hassle today!
The package name through apt on Ubuntu is the same as CentOS too, so just needs an
apt-get install cloud-utils


#3

Glad it helped Lawrence, even one person saved hassle is a plus in this game :smiley:

It should work on any flavour of *NIX with the right package manager and package name for the install, and thanks for being a trooper and confirming it’s a good to go on Ubuntu too.


#4

Thank you so much
worked for me too


#5

Glad it helped :grinning:


#6

Apologies for newbie-like question, but does this procedure allow to preserve data when migration VPS to another one with larger disk space?
And btw, in the above nomenclature, sda stands for old partition and sdb stands for a new one?

Currently, I use VPS SSD 1 2016 and I’d like migrate to VPS SSD 1 2018 which offers twice more disk space, but I’ve learned so far that this migration requires booting to recovery mode and it’s destructive for the data.
Also, my root partition is mounted as /dev/vda1.

So, the other option it to buy a new VPS and let the old one to expire after migration, or buy an additional disk.

Thanks!


#7

Hi, first only the primary disk is mentioned that’s ‘sda’ in the above, no ‘sdb’ as there is no creation it’s only allocation and growing of available space :slight_smile:

I’m not sure how the process works for migration from a 2016 to a 2018 VPS but if it’s the same as the 2018 to 2018 then you just upgrade your package and it’s the same process as above (that was on a 2018 VPS upgraded from SSD1 to SSD2), so do the migrate first and check again the designation for your disk, it’s possible that 2016 VPS’s used ‘vda’ and 2018’s use ‘sda’.

So do a backup or snapshot of your VPS if you can first, then your package upgrade and check everything’s working okay.

Check the disk designation (sda, vda, etc.)

If you disk is now named ‘sda’ it’s just as above (you don’t say which OS so for CentOS it’s ‘yum’ command line and whichever one suits for others, the package name to install is the same), if it’s still ‘vda’ then simply replace ‘sda’ with ‘vda’ and your done.

One disclaimer, I don’t know your system setup so cannot say that absolutely 100% this will work so definitely back up or snapshot your VPS first (would be worth it to purchase the snapshot add-on for a month just to make sure).

Hope I’ve answered clearly for you, if not just ask, let me know how it goes :smiley:


#8

Many thanks for your quick reply! :slight_smile:
This is the output from lsblk:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 10G 0 disk
└─vda1 253:1 0 10G 0 part /

My OS is Ubuntu 16.04.6 (upgraded manually from 15.10). I’m using VPS 2016 SSD 1 and I see an option to upgrade to VPS 2018 SSD 1 (with 20GB of disk space).
So, I assume that after upgrading I should simply have larger vda disk and my task would be to resize the (virtual) disk first: “growpart /dev/vda 1” and then the root partition “resize2fs /dev/vda1”.
Of course I can make a snapshot, but I was curious if the above operation results in losing data?
According to this doc (sorry, it’s in Polish, but it should be still clear enough), it’s a destructive operation when we perform resize in rescue mode:
https://docs.ovh.com/pl/vps/zmiana-rozmiaru-partycji-vps-upgrade/

Thanks!


#9

Hi again :slight_smile:
I’ve used the above several times now and not had any issues with it, the difference is in using the Cloud Linux tools for this making the whole operation as simple and safe as it should be.

The process of resizing from rescue boot can be destructive if it doesn’t go well and it’s a bit of a gamble to be honest, I really don’t like using it as the more reliable tools for resizing are not available on rescue boot so if your unsure I’d avoid it.

On Ubuntu the command to install the cloud linux package is above kindly provided by LawrenceO in his post - apt-get install cloud-utils

If you have a straight package upgrade option with no warnings about loosing data then you should be able to upgrade your package, check disk ID and if the disk ID is the same use the slightly modified (for your system) commands below :smiley:


apt-get install cloud-utils

growpart /dev/vda 1 (notice space before the 1 and this will allocate all available free space)

resize2fs /dev/vda1

PS don’t know why but the forum seems to want to make that last line huge :smile:


#10

Thanks - everything worked perfectly. :slight_smile:

After I selected an upgrade option and my requested was processed I was able to see enlarged disk:

lsblk

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 20G 0 disk
└─vda1 253:1 0 10G 0 part /

So, I run the first command to modify the partition table for partition 1:

growpart /dev/vda 1

CHANGED: partition=1 start=2048 old: size=20969439 end=20971487 new: size=41940959,end=41943007

And then I resized the actual partition:

resize2fs /dev/vda1

resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/vda1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/vda1 is now 5242619 (4k) blocks long.

It was pretty straight-forward and quick ; df -h showed that resize was successful. :slight_smile: And most importantly, it was non-destructive operation.

/dev/vda1 20G 8.6G 11G 45% /

I rebooted my vps to ensure that everything’s fine after reboot too and it’s fine indeed.

Again, thanks a lot for your help! :slight_smile:


#11

Brilliant, sorry I didn’t get any notification you’d replied, and got a bit worried to be honest.
I’m happy if it helps some one :slight_smile: