Resize virtual disk to >3TB

Submitted by allitsk on Tue, 09/02/2014 - 11:56

Today I try resize virtual disk by Cloudmin web interface to >3TB. Hardisk had a GPT table and >2TB partition on it.

Cloudmin script return this error: Updating virtual disk on /dev/datavg/server_company_local_2_img .... .. update failed : parted -s \/dev\/datavg\/server_company_local_2_img mkpart ext4 1048576B 3758096M failed : Warning: Not all of the space available to /dev/dm-1 appears to be used, you can fix the GPT to use all of the space (an extra 2097152000 blocks) or continue with the current setting? Error: You requested a partition from 1049kB to 3758GB. The closest location we can manage is 1049kB to 2684GB.

...and, of course, let a virtual disk corrupted = without any partition.

Is possible to fix GPT by cloudmin automatically? Or if any error reported create original partition setup back?

Thank You.

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Tue, 09/02/2014 - 13:36

Wow, that's bad. I guess I never expected that someone would create a VM with a 3 TB disk.

Did the virtual disk have only a DOS format partition table?

Submitted by allitsk on Tue, 09/02/2014 - 14:39

We have a few clients with big file servers, full of active data, and not each time we can split them to small pieces - partitions.

In this situation virtual disk has a GPT partition table before resizing (was >2TB before).

We have a some other problems with this.

For example, Cloudmin create new virtual disk with MBR partition table by default. We need to grow disk to >2TB (limit for MBR) after some time and with Cloudmin we would corrupt disk. There is no check before resizing. It's take plenty of time to repair it.

Convert MBR to GPT ist not so easy and must be done carefully, but it's necessary to check if resize is possible before do it. Here is tool to to convert MBR to GPT: https://wiki.archlinux.org/index.php/GUID_Partition_Table#Convert_from_M...

Submitted by JamieCameron on Tue, 09/02/2014 - 21:56

I will switch Cloudmin to creating GPT disklabels by default on new disks in future.

However, it sounds like this wouldn't solve your problem exactly as a GPT label on a small disk cannot necessarily be used with a larger disk. And it isn't clear now to expand the label :-(

Submitted by allitsk on Wed, 09/03/2014 - 01:03

I think that the best resolution would be set GPT as default on new disk (as you suggest) and add check before resizing to find out if it's possible to resize before do it (before remove original partition). Or after a error try to take all changes back.

I wrote about two problems with different characters, the first one has easy solution (answer YES to question before creating new partition), second is complicated and would be resolved by admin manually. But it's necessary to check before corrupt disk.

All checks are really needed especially for scheduled resizing. One time I used it and I had a server down for hours, until morning.

Submitted by JamieCameron on Wed, 09/03/2014 - 18:10

What I'll do to prevent a partition delete/re-create from being a disaster is use the built-in resize function in parted where available. This will be done in the next Cloudmin release.

Submitted by JamieCameron on Thu, 09/04/2014 - 00:02

Actually the resize function in parted doesn't work as expected - it only resizes a filesystem within a partition.

So the next release of Cloudmin will roll back a failed partition size increase if needed, and will use GPT by default.

Submitted by Issues on Thu, 09/18/2014 - 00:11

Automatically closed -- issue fixed for 2 weeks with no activity.