# How to extend a block storage volume

Source: https://docs.quake.ai/docs/block/how-to/extend-volume
Markdown: https://docs.quake.ai/docs/block/how-to/extend-volume.md

---

# 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.



A volume's capacity can grow but cannot shrink. Confirm the new size is correct before proceeding.





**Online extend needs Cinder microversion 3.42 or later.** At microversion 3.42 or later, you can extend a volume while it stays attached and in-use. If the request lands at an earlier microversion, Cinder rejects the extend and you detach the volume first.

The CLI and API select the microversion, so the message you see depends on which microversion the call lands on. At the CLI default microversion or at a microversion earlier than 3.42, an in-use extend fails with `Failed to set volume size: Volume is in in-use state, it must be available before size can be extended`.



<PrerequisiteBlock methods={["console", "cli", "api"]}>

- 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)

</PrerequisiteBlock>

## 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.

<MethodTabs>
<Method label="Console">

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

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

</Method>
<Method label="CLI">

```bash
export OS_VOLUME_API_VERSION=3.42
openstack volume set --size NEW_SIZE VOLUME_NAME
```

Replace `NEW_SIZE` with the new size in GiB, larger than the current size. With microversion 3.42 or later, the volume stays attached and in-use throughout. Without the microversion, the CLI default rejects the in-use extend with `Failed to set volume size: Volume is in in-use state, it must be available before size can be extended`.

</Method>
<Method label="API">

<BlockApiEnvPrereqs />

```bash
curl -X POST "$OS_VOLUME_URL/volumes/VOLUME_ID/action" \
  -H "OpenStack-API-Version: volume 3.42" \
  -H "X-Auth-Token: $OS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"os-extend": {"new_size": NEW_SIZE}}'
```

The `OpenStack-API-Version: volume 3.42` header returns `202 Accepted` and the volume stays in-use. A request at a microversion earlier than 3.42 returns `400 Bad Request` because the volume's status must be `available`.

</Method>
</MethodTabs>

## 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.

<MethodTabs>
<Method label="Console">

<NoMoreButton />

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

The volume status transitions from **In-use** to **Available**.

</Method>
<Method label="CLI">

```bash
openstack server remove volume INSTANCE_NAME VOLUME_NAME
openstack volume show VOLUME_NAME -c status -f value
```

Wait until `openstack volume show` reports `available` before continuing.

</Method>
<Method label="API">

```bash
curl -X DELETE "$OS_COMPUTE_URL/servers/INSTANCE_ID/os-volume_attachments/VOLUME_ID" \
  -H "X-Auth-Token: $OS_TOKEN"
```

Poll the volume status until it returns `available`.

</Method>
</MethodTabs>

### Extend the detached volume

<MethodTabs>
<Method label="Console">

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

</Method>
<Method label="CLI">

```bash
openstack volume set --size NEW_SIZE VOLUME_NAME
```

Replace `NEW_SIZE` with the new size in GiB. The detached volume extends at the default microversion.

</Method>
<Method label="API">

```bash
curl -X POST "$OS_VOLUME_URL/volumes/VOLUME_ID/action" \
  -H "X-Auth-Token: $OS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"os-extend": {"new_size": NEW_SIZE}}'
```

</Method>
</MethodTabs>

### Reattach the volume

<MethodTabs>
<Method label="Console">

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

</Method>
<Method label="CLI">

```bash
openstack server add volume INSTANCE_NAME VOLUME_NAME
```

</Method>
<Method label="API">

```bash
curl -X POST "$OS_COMPUTE_URL/servers/INSTANCE_ID/os-volume_attachments" \
  -H "X-Auth-Token: $OS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"volumeAttachment": {"volumeId": "VOLUME_ID"}}'
```

</Method>
</MethodTabs>

After reattaching, grow the filesystem inside the instance as shown in [Resize the filesystem inside the instance](#resize-the-filesystem-inside-the-instance).

## Verify the result

<MethodTabs>
<Method label="Console">

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

</Method>
<Method label="CLI">

```bash
openstack volume show VOLUME_NAME -c size -c status
```

Confirm `size` matches the requested capacity and `status` reads `in-use` (or `available` if the volume is detached).

</Method>
<Method label="API">

```bash
curl -s "$OS_VOLUME_URL/volumes/VOLUME_ID" \
  -H "X-Auth-Token: $OS_TOKEN" \
  | python3 -c "import sys,json; v=json.load(sys.stdin)['volume']; print(v['size'], v['status'])"
```

</Method>
</MethodTabs>

## See also

- [Volumes concepts](/docs/block/concepts/volumes)
- [Create a volume](/docs/block/how-to/create-volume)
- [Clone a volume](/docs/block/how-to/clone-volume)