How to extend a block storage volume

How-to · Updated Sep 2026

Coming from another cloud?

▸AWS·Amazon EBS volumes

Amazon EBS volumeshigh

Strictly bound to a single Availability Zone where created; cannot be moved without snapshot.
Multiple volume types (gp3, io2, st1) with different performance/billing characteristics; Cinder uses volume_types but backend-defined.
Billed per provisioned GB-month regardless of usage; OpenStack typically quota-based without standard usage billing.
API via EC2 CreateVolume; differs from Cinder create_volume.

AWS docs ↗

▸Azure·Managed Disks

Azure Managed Diskshigh

Azure Managed Disks are fully managed with automatic redundancy (3 replicas, 99.999% SLA); Cinder durability depends on backend.
Predefined disk types (Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD, Standard HDD) with fixed performance tiers; Cinder uses volume types with configurable QoS.
Disks billed on provisioned size regardless of use; Cinder billing typically on provisioned size too but varies by provider.

Azure docs ↗

▸DigitalOcean·Volumes

Volumeshigh

Uses proprietary /v2/volumes API instead of OpenStack Cinder /v3/{project_id}/volumes; actions like attach/detach/resize via undocumented POST /volumes/{id}/actions rather than /os-volume-attach etc.
Enforces single-instance attachment only (one Droplet at a time); OpenStack supports multi-attach volumes.
Volume names must be globally unique per region; OpenStack uses IDs primarily with optional display names.
Size specified in GiB (binary) with 1 GiB to 16 TiB range; OpenStack typically GiB but flexible.

DigitalOcean docs ↗

▸Google Cloud·Persistent Disk

Persistent Diskhigh

Uses Google Compute Engine REST API instead of OpenStack Cinder API.
Offers multiple performance tiers (pd-standard HDD, pd-balanced SSD, pd-ssd, pd-extreme) with performance scaling linearly with provisioned size, unlike Cinder's backend-dependent performance.
Supports regional disks replicated synchronously across 2 zones for higher availability (better than 99.9999% durability), while Cinder volumes are typically zonal unless using replication features.
Online resize to increase size without detaching; no manual striping/RAID needed as GCP handles distribution automatically.

Google Cloud docs ↗

▸Hetzner·Cloud Volumes

Cloud Volumeshigh

Provisioned via Hetzner CSI driver (csi.hetzner.cloud), ReadWriteOnce only, min 10GB, NVMe-based.
Billed €0.044/GB/month until deleted, no pause; attach/detach via CSI, unlike Cinder's broader access modes (RWX via Manila).
Snapshots supported but no volume encryption at rest by default; location-specific (e.g., fsn1).
Proprietary REST API at https://api.hetzner.cloud/v1/volumes using Bearer token auth, not OpenStack Cinder API (v3 JSON over Keystone). Endpoints like POST /volumes/{id}/actions/attach, POST /volumes/{id}/actions/resize (upsize only). No /v3/{project_id}/volumes/{volume_id}/action os-extend.

Hetzner docs ↗

Before this

Volumes

How to extend a block storage volume

Increase the capacity of an existing block storage volume. Volume extensions are irreversible: capacity can only grow. Quake AI's Cinder supports online extend on an attached, in-use volume when you issue the request at Cinder API microversion 3.42 or later. Set the microversion, extend the volume while it stays attached, then grow the filesystem inside the instance with no unmount or detach. If you call at an earlier microversion, fall back to the detach, extend, and reattach sequence.

Prerequisites

ConsoleLogged in to the Quake AI console
CLIOpenStack CLI installed and authenticated (clouds.yaml or openrc sourced)
APIAPI token generated with $OS_TOKEN and service endpoint variables set

Windows: CLI examples use bash. Set up a Linux CLI environment on Windows before proceeding.

An existing block storage volume
CLI or API access if you want to control the Cinder microversion (online extend needs 3.42 or later)
Access to the instance using the volume, to grow the filesystem after extending (and to detach and reattach the volume for the pre-3.42 fallback)

Extend the volume#

At Cinder microversion 3.42 or later, you can extend the volume while it stays attached and in-use. The CLI and API set the microversion explicitly; after the extend, grow the filesystem inside the instance.

Go to Storage > Volumes.
Locate the volume row.
Open the Volume action icon dropdown on the row and select Extend Volume.
Set the new capacity in GiB (must be larger than the current size).
Select OK.

The console does not expose the API microversion. To control the microversion explicitly for an attached volume, use the CLI or API.

Resize the filesystem inside the instance#

The block device on the instance now reports the new size, but the filesystem still spans the old extent. SSH into the instance and grow the filesystem to fill the device:

bash

# Confirm the block device shows the new size
lsblk

# For ext4 filesystems (online resize while mounted)
sudo resize2fs /dev/sdb

# For XFS filesystems (online resize while mounted)
sudo xfs_growfs /dev/sdb

Quake AI's libvirt driver uses virtio-scsi, so attached volumes show up as /dev/sdX (for example, /dev/sdb) inside the instance. Confirm the actual path with lsblk before resizing.

Extend a detached volume (pre-3.42 fallback)#

If your CLI or SDK pins to a Cinder microversion earlier than 3.42, the extend is rejected on an in-use volume. Detach the volume, extend it, reattach it, then resize the filesystem. The application running on the instance is unavailable during the detach window.

Detach the volume#

Skip this step if the volume is already in Available status.

Go to Storage > Volumes.
Locate the volume row.
Open the Volume action icon dropdown on the row and select Detach (the menu item visible while the volume is In-use).
Confirm the detach.

The volume status transitions from In-use to Available.

Extend the detached volume#

Go to Storage > Volumes.
Locate the (now Available) volume row.
Open the Volume action icon dropdown on the row and select Extend Volume.
Set the new capacity in GiB (must be larger than the current size).
Select OK.

Reattach the volume#

With the volume still in the list, open the Volume action icon dropdown on its row and select Attach.
Pick the instance the volume was previously attached to.
Confirm the attach.

After reattaching, grow the filesystem inside the instance as shown in Resize the filesystem inside the instance.

Verify the result#

Go to Storage > Volumes. The volume shows the new capacity and reads as In-use while attached.

Usage Guidelines

The sample code, software libraries, command line tools, proofs of concept, templates, and other related technology on this page (including any of the foregoing that is provided by Quake AI personnel) is provided to you as Quake AI Content under the Quake AI Customer Agreement, or the relevant written agreement between you and Quake AI (whichever applies). Do not use this Quake AI Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the Quake AI Content (such as sample code) as appropriate for production grade use based on your specific quality control practices and standards. Deploying Quake AI Content may incur Quake AI charges for creating or using Quake AI chargeable resources, such as running Compute instances or storing data in Object Storage. Your use is also subject to the Acceptable Use Policy.

For the full policy, see Usage Guidelines.

Last validated: 01.09.2026

Was this page helpful?

How to extend a block storage volume

How to extend a block storage volume

Extend the volume#

Resize the filesystem inside the instance#

Extend a detached volume (pre-3.42 fallback)#

Detach the volume#

Extend the detached volume#

Reattach the volume#

Verify the result#

See also#

Usage Guidelines

Quick answers

See Also