A volume is a persistent block storage device that you attach to an instance. The operating system inside the instance sees it exactly as it would a physical disk: you can partition it, format it with any filesystem, and mount it at any path. Under the hood, the platform stores volume data on a distributed storage backend and presents it to the hypervisor as a virtual disk.

The key distinction from an instance's root disk is lifecycle: the root disk is tied to the instance and deleted with it (unless you snapshot it first). A volume persists independently. You can detach it from one instance, attach it to another, and the data comes along.

The Block Storage service is backed by OpenStack Cinder.

All volumes use premium NVMe flash storage. There is one storage tier: Flash_Premium: and it applies to all volumes regardless of size. No spinning-disk tiers or separate IOPS SKUs exist; performance characteristics are uniform across the offering.

Volume sizes range from 1 GiB to 29,800 GiB. You set the size when you create the volume. You can extend a volume after creation (increase size only; shrinking is not supported).

You can create a volume from the console, CLI, or API. With the CLI:

# Create a blank 50 GiB volume
openstack volume create --size 50 my-volume

# Attach it to a running instance
openstack server add volume my-instance my-volume

After attaching, the volume appears as a new block device (for example, /dev/sdb) inside the instance. You must format and mount it before use. In the console, go to Storage > Volumes > Create Volume, then attach via Compute > Instances > More > Attach Volume.

A volume can also be created from an existing image or snapshot at creation time, which pre-populates it with data.

Use volumes when your application needs a filesystem with random read/write access and you want the data to survive instance replacements.

These three concepts are related but serve different purposes:

• Volume snapshot: a point-in-time copy of an individual storage volume, stored incrementally (only changed blocks since the last snapshot). It depends on the source volume for deletion: you must delete dependent snapshots before you can delete the source volume. Use volume snapshots for scheduled backups and restore points for specific data disks.

• Volume clone: a new, fully independent volume created from an existing volume or snapshot. Unlike a snapshot, a clone is a standalone volume you can attach and use immediately. Changes to the clone do not affect the source, and vice versa. Use clones to spin up test environments from production data or to scale out database replicas with pre-loaded data.

• Instance snapshot: captures the full state of a running instance's root disk (not attached Cinder volumes) and stores the result as a new image in the Image service. It is immutable once created and can be used to launch new instances. Use instance snapshots when you need the complete machine image, not the data from a single attached disk.

Choose instance snapshots for full VM images. Choose volume snapshots or clones to protect data on specific attached volumes independently of the instance.

A volume moves through a predictable set of states:

Operations are only valid from certain states. Attempting an operation from the wrong state returns a 409 Conflict API error. If a volume is stuck in a transitional state for more than about 10 minutes, see the troubleshooting runbook.

Quake AI does not offer native Cinder volume backups. Use volume snapshots for point-in-time recovery or volume clones for full independent copies.

Yes. Volumes support encryption for data at rest, providing an additional layer of protection for sensitive data. Multi-tenancy also isolates volumes and snapshots between projects; other tenants cannot access your storage.

You can extend a volume while it is either available (detached) or in-use (attached). Extending an attached volume online requires Cinder API microversion 3.42 or later: set OS_VOLUME_API_VERSION=3.42 (or pass --os-volume-api-version 3.42) before you run the resize.

# Extend an attached volume to 100 GiB (online, microversion 3.42+)
OS_VOLUME_API_VERSION=3.42 openstack volume set --size 100 my-volume

Important: Extension is irreversible. You can only increase size, never decrease it. After extending the volume at the platform level, resize the filesystem inside the instance to use the new space:

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

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

Replace /dev/sdb with the actual device path inside your instance. Quake AI attaches volumes over virtio-scsi, so they appear as /dev/sdX, not /dev/vdX.

Online extend of an attached (in-use) volume requires Cinder API microversion 3.42 or later. At the CLI default microversion or at any 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

Set the microversion and run the resize while the volume stays attached:

# Online extend on the attached volume (microversion 3.42+)
OS_VOLUME_API_VERSION=3.42 openstack volume set --size 100 MY_VOLUME_NAME

# Grow the filesystem inside the instance, no unmount needed
sudo resize2fs /dev/sdb   # ext4
sudo xfs_growfs /dev/sdb  # XFS

If you cannot pin microversion 3.42 or later, use the legacy detach, extend, re-attach sequence:

# Legacy fallback (pre-3.42): detach, extend, re-attach
openstack server remove volume MY_INSTANCE_NAME MY_VOLUME_NAME

# Wait for the volume to reach 'available'
openstack volume show MY_VOLUME_NAME -c status

# Extend, then re-attach
openstack volume set --size 100 MY_VOLUME_NAME
openstack server add volume MY_INSTANCE_NAME MY_VOLUME_NAME

After re-attaching, grow the filesystem inside the instance with resize2fs /dev/sdb (ext4) or xfs_growfs /dev/sdb (XFS), substituting the actual device path. Extension is irreversible; you can only increase size, never decrease it.

# Snapshot a detached (available) volume
openstack volume snapshot create --volume my-volume my-snapshot

# Force a snapshot of an attached (in-use) volume
openstack volume snapshot create --volume my-volume --force my-snapshot

For the most consistent snapshot, quiesce write activity or flush buffers before taking a snapshot of an actively attached volume. A snapshot of an actively written volume captures a crash-consistent state, acceptable for many workloads, but database-level consistency requires application-level coordination (for example, FLUSH TABLES WITH READ LOCK for MySQL).

Snapshots are incremental: only changed blocks since the last snapshot are stored, making them space-efficient for regular backup schedules.

Cloning creates a new, fully writable, independent volume. The clone size must be equal to or larger than the source:

openstack volume create \
  --source SOURCE_VOLUME_ID \
  --size 50 \
  my-cloned-volume

In the console, go to Storage > Volumes, select the volume, then choose More > Data Protection > Clone Volume.

Transferring ownership moves a volume from one Quake AI project to another without physically moving the data, only the ownership metadata changes. The volume must be in Available status (not attached) before the transfer.

The process is two-step:

Step 1: Source project creates the transfer:

openstack volume transfer request create --name my-transfer my-volume
# Returns a Transfer ID and Auth Key, share both securely with the recipient

Step 2: Target project accepts the transfer:

source ~/path/to/target-project-openrc.sh
openstack volume transfer request accept --auth-key AUTH_KEY TRANSFER_ID

The source project can cancel a pending transfer before acceptance with openstack volume transfer request delete TRANSFER_ID.

• Size with headroom. You can extend volumes but not shrink them. Start larger than your current minimum and monitor usage.
• Store growing data on volumes, not the root disk. The root disk size follows the instance flavor and cannot be extended the way a Cinder volume can.
• Detach before snapshot when consistency matters. Quiesce writes or stop the application before snapshotting for database-level consistency.
• Clean up unused volumes. Detached volumes sitting in the available state still consume quota. Delete volumes and old snapshots you no longer need.
• Avoid rapid attach/detach loops. Wait for each operation to reach a stable state before starting the next.
• Automate snapshot schedules. Regular snapshots protect against accidental data loss; automate them via the CLI or API.

Application-credential openrc files export Keystone auth variables but not OS_TOKEN or the project-scoped Cinder URL. API tab examples that call $OS_VOLUME_URL/volumes fail until you export both values in the same shell:

OS_TOKEN=$(openstack token issue -f value -c id)
OS_VOLUME_URL="https://volume.${OS_REGION_NAME}.rumble.cloud/v3/$(openstack token issue -f value -c project_id)"

Re-run those exports after you source a different project's openrc so the token and volume URL match the project you are testing.

A volume stays in a transitional state when the API operation timed out (for example HTTP 504), the storage backend encountered an error, Nova–Cinder coordination broke down, or a Heat stack changed volume state mid-operation.

Diagnosis:

openstack volume show VOLUME_ID -c status -c attachments

If attachments is empty but status is still attaching or detaching, reset to a stable state:

openstack volume set --state available VOLUME_ID

If a stale attachment row exists but the instance no longer exists, remove it first:

openstack volume attachment list --volume VOLUME_ID
openstack volume attachment delete VOLUME_ID ATTACHMENT_ID
openstack volume set --state available VOLUME_ID

If the state reset does not clear the stuck state, or attachments reappear after deletion, open a support ticket with the volume ID and UTC timestamps.

openstack volume delete fails with in-use or dependency errors when one or more of the following conditions applies:

• The volume is still attached to an instance
• An orphaned attachment record exists after the instance was deleted
• Snapshots of the volume exist: Cinder requires you to delete all dependent snapshots before deleting the source volume
• The volume belongs to a consistency group

Resolution steps:

1. Check for attachments and snapshots:

openstack volume show VOLUME_ID -c attachments -c status
openstack volume snapshot list --volume VOLUME_ID

1. Detach from a live instance:

openstack server remove volume SERVER_NAME_OR_ID VOLUME_ID

1. Delete snapshots first:

openstack volume snapshot delete SNAPSHOT_ID

1. If an orphaned attachment remains (instance gone), delete the attachment record and reset state:

openstack volume attachment delete VOLUME_ID ATTACHMENT_ID
openstack volume set --state available VOLUME_ID

1. Retry deletion.

Snapshot creation fails or stalls when:

• The source volume is in a transitional state (creating, attaching, detaching, extending): Cinder requires it to be available or in-use
• The storage backend is under concurrent load
• Volume or gigabyte quota is exhausted

Diagnosis:

openstack volume show VOLUME_ID -c status
openstack quota show --usage

If the source volume is in a transitional state, wait until it settles, then retry. If the snapshot remains creating for more than about 10 minutes after the source volume is stable and quota is healthy, delete the stuck snapshot and retry. If failures persist, open a support ticket. You may need operator action on the backend.

Prevention: Do not start snapshots during resize, attach, or detach operations.

When df -h shows the root filesystem (or another mount) at 100%, applications log write errors or crash, and SSH may become slow or unresponsive.

Identify what is consuming space:

df -h
sudo du -sh /var/log/* 2>/dev/null | sort -h

Common fixes:

• Trim systemd journal:

sudo journalctl --vacuum-size=100M

• Remove rotated/compressed old logs (accept data loss):

sudo rm /var/log/*.gz

• Clear safe temporary directories.
• For durable extra capacity, attach a Cinder volume for application data and move large directories there.

Note: The root disk size is set by the instance flavor and cannot be extended the way a Cinder volume can. If root disk growth is the underlying problem, attach a volume for large, growing data directories instead of relying on the root disk.

If SSH is unavailable, use the instance console:

openstack console url show SERVER_NAME_OR_ID

Gather the following before contacting support for volume issues:

A Cinder volume on Quake AI is the direct equivalent of an AWS EBS volume. The lifecycle operations are the same: create, attach to one instance at a time, format, mount, snapshot, detach, and delete.

The key difference: AWS segments EBS into multiple types (gp3, io2, st1, sc1) with provisioned IOPS tiers and per-GB/per-IOPS billing. Quake AI exposes Cinder volumes backed by NVMe at every tier: there are no separate IOPS SKUs, no provisioned throughput options, and no per-second metering.

For the full AWS-to-Quake AI mapping table and migration guidance, see Coming from AWS: Block storage.

A Cinder volume. The attach lifecycle matches DigitalOcean Block Storage closely enough that existing operational runbooks port with API surface changes only. Both platforms back block storage with NVMe at all tiers; on Quake AI you do not pick separate performance SKUs.

The API layer changes from DigitalOcean's proprietary API to the OpenStack Cinder API (openstack volume commands). Capacity and attachment limits still apply per project.

A Cinder volume. You create a volume, attach it to one instance, format, mount, snapshot, and detach, the same workflow as GCP Persistent Disks.

The key difference: GCP segments Persistent Disks into pd-standard, pd-balanced, pd-ssd, and pd-extreme with provisioned IOPS tiers. Quake AI exposes Cinder volumes backed by NVMe with the same attach/detach workflow and no separate IOPS tiers.

A Cinder volume. You create a disk, attach it to one VM, format, mount, snapshot, and detach, the same workflow as Azure Managed Disks.

The key difference: Azure offers Premium SSD, Standard SSD, Standard HDD, and Ultra Disk with provisioned IOPS. Quake AI exposes Cinder volumes backed by NVMe with no separate IOPS tiers: Premium/Standard SSD distinctions collapse into a single NVMe tier.

A Cinder volume. Hetzner and Quake AI use the same create/attach/detach/snapshot model, and both back block storage with NVMe. The operational difference is the API layer: Hetzner uses hcloud, Quake AI uses OpenStack Cinder (openstack volume commands).

The corpus has no dedicated per-provider block volume migration guide. The general migration pattern for block data is:

1. Provision a new Cinder volume on Quake AI.
2. Attach it to a Quake AI instance.
3. Transfer data from the source instance using rsync, dd, or standard database dump/restore tools.

For full VM migrations (including root disk data), refer to the Compute migration guides, which cover the rebuild-and-rsync approach for AWS EC2, GCP, Azure VMs, DigitalOcean Droplets, and Hetzner Servers. Block data moves as part of that workflow.

Block Storage runs in all three Quake AI regions: us-east-1, us-east-2, and us-west-1. Each region is an independent failure domain; a volume created in one region cannot be attached to an instance in another. Quake AI uses regions, not availability zones, so volume placement does not require an AZ choice; a volume attaches to any instance in the same region. See Regions for the current region table and console URLs.

The contractual availability target and credit schedule are published as part of Quake AI's commercial terms at rumble.cloud/legal. The Service Level Agreement page explains how to read those terms and how to file a credit claim. Volumes are zonal storage: a single volume lives in one region and is not automatically replicated across regions. For data durability beyond the SLA's protection, pair regular volume snapshots with application-level replication and (where appropriate) object-storage backups in a second region.

For most problems, start with the relevant runbook or reference:

• Volume troubleshooting runbook: stuck volumes, delete failures, snapshot failures, disk exhaustion
• Block storage API error reference: HTTP status codes, state machine errors, and recovery steps

If the runbook does not resolve the issue, open a support ticket with the volume UUID, the region, the UTC time window for the failing operation, the last commands you ran, and the output of openstack volume show VOLUME_ID -c id -c status -c attachments and openstack quota show --usage. See Support ticket evidence collection for the full evidence checklist and Get help for the canonical decision tree by symptom.