How to Expand Storage on a Cloud Server

Before You Begin: Block Storage or Local Storage?

When your cloud server runs low on disk space, the expansion method depends on which type of storage needs more capacity. Understanding this distinction is essential before proceeding.

Check your current disk usage:

1df -h
Copy

This shows which filesystems are nearing capacity. The mount point and device name indicate the storage type.

Identify the storage type:

• Local storage: Device /dev/vda, mount point / (root), managed by flavor (resize required)

• Block storage: Device /dev/vdb, /dev/vdc, mount point /data, /mnt/volume, managed by Cinder (expand online)

Option 1: Expand a Block Storage Volume

Use this method when additional capacity is needed on an attached Cinder block storage volume. Block storage volumes can be expanded without changing your server's CPU, RAM, or flavor.

Prerequisites

• A running InMotion Cloud server with an attached volume

• Access to the InMotion Cloud Horizon dashboard or OpenStack CLI

• Administrative access (sudo) within the server

• A current backup of the volume data

Understand the Expansion Process

Expanding a volume involves three distinct steps:

1. Extend the volume at the OpenStack/InMotion Cloud layer (increases block device size)

2. Expand the partition if the filesystem is inside a partition

3. Grow the filesystem to use the new space

OpenStack does not automatically extend partitions or filesystems. You must complete all three steps to see the additional space in df -h.

Step 1: Extend the Volume (Horizon)

1. Navigate to Project > Volumes > Volumes

2. Locate the volume you want to resize

3. Click the dropdown arrow next to the volume and select Extend Volume

4. Enter the new size in GiB (must be larger than current size)

5. Click Extend Volume to confirm

The volume status briefly shows "extending" then returns to "in-use" or "available."

Step 1 (Alternative): Extend the Volume (CLI)

For attached volumes, use the volume API version 3.42 or higher:

1openstack volume set --size NEW_SIZE_GB VOLUME_ID
Copy

Replace VOLUME_ID with your volume's ID or name, and NEW_SIZE_GB with the new size in gigabytes.

Example:

1openstack volume set --size 100 my-data-volume
Copy

Step 2: Verify the New Block Device Size

After extending the volume at the OpenStack layer, verify the server detects the new size:

1lsblk
Copy

Expected output shows the new size:

1NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
2vdb    252:16   0  100G  0 disk
3└─vdb1 252:17   0   50G  0 part /data
Copy

If lsblk still shows the old size, rescan the SCSI bus:

1echo 1 | sudo tee /sys/class/block/vdb/device/rescan
Copy

Or for specific device rescan:

1sudo rescan-scsi-bus.sh
Copy

Step 3: Expand the Partition (If Applicable)

If your filesystem is inside a partition (e.g., /dev/vdb1 rather than directly on /dev/vdb), expand the partition first.

Install growpart if needed:

1# Debian/Ubuntu
2sudo apt install cloud-guest-utils
3
4# RHEL/CentOS/Rocky
5sudo dnf install cloud-utils-growpart
Copy

Expand the partition:

1sudo growpart /dev/vdb 1
Copy

Replace /dev/vdb with your device and 1 with the partition number.

Verify the partition expanded:

1lsblk
Copy

The partition should now show the full device size.

Step 4: Expand the Filesystem

The final step depends on your filesystem type.

Identify the filesystem type:

1df -T /data
Copy

For ext4 Filesystems:

1sudo resize2fs /dev/vdb1
Copy

Replace /dev/vdb1 with your actual device or partition.

For XFS Filesystems:

XFS requires the mount point rather than the device:

1sudo xfs_growfs /data
Copy

Replace /data with your actual mount point.

Step 5: Verify the New Capacity

Confirm the filesystem now shows the expanded size:

1df -h /data
Copy

Expected output:

1Filesystem      Size  Used Avail Use% Mounted on
2/dev/vdb1       100G   25G   75G  25% /data
Copy

The additional space is now available for use.

Option 2: Increase Local Storage by Resizing the Server

Use this method when you need more capacity on your root disk or local storage that is part of your server's flavor. Resizing changes your server to a different flavor with more disk allocation.

Understand Flavor Resize

A flavor defines your server's resource allocation: CPU, RAM, and local disk. Increasing local storage requires selecting a flavor with a larger disk allocation, which may also change CPU and RAM.

This is different from block storage expansion:

• Block Storage Expansion: No downtime (online expansion), affects single volume only, expand any amount

• Flavor Resize: Yes downtime (server reboot), affects CPU, RAM, and disk, limited to available flavors

If your only requirement is additional data storage capacity, consider adding or expanding block storage instead of resizing the entire server.

Prerequisites

• Access to the InMotion Cloud Horizon dashboard or OpenStack CLI

• Knowledge of your current and target flavor specifications

• A current backup of your server data

• Scheduled maintenance window (server will reboot)

Step 1: Check Your Current Flavor

In Horizon:

1. Navigate to Project > Compute > Instances

2. Click your instance name to view details

3. Note the current flavor under "Flavor"

Using CLI:

1openstack server show YOUR_SERVER_NAME -f value -c flavor
Copy

Step 2: Identify a Target Flavor

List available flavors to find one with sufficient disk allocation:

In Horizon:

1. Navigate to Project > Compute > Instances

2. Click the dropdown arrow next to your instance

3. Select Resize Instance to see available flavors

Using CLI:

1openstack flavor list
Copy

Review the disk column and select a flavor with the required local disk capacity. Note that CPU and RAM will also change to match the new flavor.

Step 3: Back Up Your Data

Before resizing:

• Create a snapshot of your instance

• Back up critical data to block storage or external location

• Document your current configuration

Step 4: Resize the Server (Horizon)

1. Navigate to Project > Compute > Instances

2. Click the dropdown arrow next to your instance

3. Select Resize Instance

4. Choose the target flavor with larger disk allocation

5. Click Resize

The instance enters "RESIZE" status. This process takes several minutes as data is migrated.

Step 4 (Alternative): Resize the Server (CLI)

1openstack server resize --flavor NEW_FLAVOR_NAME YOUR_SERVER_NAME
Copy

Example:

1openstack server resize --flavor m1.large my-web-server
Copy

Step 5: Confirm the Resize

After the resize completes, the instance enters "VERIFY_RESIZE" status. You must confirm or revert.

In Horizon:

1. Click the dropdown arrow next to the instance

2. Select Confirm Resize/Migrate

Using CLI:

1openstack server resize confirm YOUR_SERVER_NAME
Copy

If something went wrong, revert instead:

1openstack server resize revert YOUR_SERVER_NAME
Copy

Step 6: Expand the Guest Filesystem

After confirming the resize, the underlying block device has more capacity, but the guest filesystem may not automatically expand.

Connect to your server and check:

1lsblk
2df -h
Copy

If lsblk shows more capacity than df -h, expand the root partition and filesystem:

For growpart + ext4:

1sudo growpart /dev/vda 1
2sudo resize2fs /dev/vda1
Copy

For growpart + XFS:

1sudo growpart /dev/vda 1
2sudo xfs_growfs /
Copy

Step 7: Verify the New Capacity

1df -h /
Copy

The root filesystem should now show the increased capacity from the new flavor.

Troubleshooting

"I expanded the volume, but df -h still shows the old size"

The block device grew, but the partition or filesystem did not expand automatically.

Diagnostic steps:

1lsblk
2df -h
Copy

Solution: Follow Steps 3 and 4 in the block storage expansion section to expand the partition and filesystem.

"lsblk still shows the old volume size"

The operating system has not detected the new block device size.

Solution: Rescan the SCSI bus:

1echo 1 | sudo tee /sys/class/block/vdb/device/rescan
Copy

Or rescan a specific device:

1sudo rescan-scsi-bus.sh
Copy

"I don't know whether this is block storage or local storage"

Run these commands:

1# Check attached volumes
2openstack server show YOUR_SERVER_NAME -c volumes_attached
3
4# List your volumes
5openstack volume list
Copy

• If the device appears in the openstack volume list output, it is block storage

• If the device is /dev/vda and not listed as an attached volume, it is local storage (part of the flavor)

"Can I expand storage without downtime?"

For zero-downtime storage expansion, use block storage volumes rather than local flavor storage.

"Can I shrink storage later?"

No. Both block storage volumes and flavor local storage can only be expanded, not reduced. Plan your storage allocation carefully, but prioritize near-term requirements rather than over-provisioning.

Related Resources

• [OpenStack Volume Management Documentation](https://docs.openstack.org/cinder/latest/admin/blockstorage-manage-volumes.html)

• [OpenStack Instance Resize Documentation](https://docs.openstack.org/nova/latest/user/resize.html)