Block Device Mapping

Overview

(BDM) gives precise control over how storage is presented to an instance at creation time. Use BDM to boot from a persistent volume, attach pre-existing data volumes, or configure the ephemeral scratch disk included in certain flavors.

Prerequisites

An active Xloud project with member or admin role
Xloud Block Storage volumes (for volume-backed launches) or images (for image-backed launches)
CLI users: Xloud CLI configured and credentials sourced

BDM Attributes Reference

Attribute	Description	Values
`source_type`	Origin of the block device	`image`, `volume`, `snapshot`, `blank`
`destination_type`	Where the device is stored	`volume` (persistent) or `local` (ephemeral)
`boot_index`	Boot priority (0 = primary boot device)	Integer; `-1` for non-bootable
`uuid`	ID of the source image, volume, or snapshot	UUID string
`volume_size`	Size of the created volume in GB	Integer
`delete_on_termination`	Whether to delete the volume when the instance is deleted	`true` or `false`

Boot from Volume

Booting from a persistent volume is recommended for production workloads. The root disk survives instance termination when delete_on_termination is set to false, enabling instance snapshots, backups, and re-attachment to replacement instances.

Dashboard
CLI

Open the Launch Instance dialog

Navigate to Project → Compute → Instances and click Launch Instance.

Configure the boot source

On the Source tab:

Set Select Boot Source to Image.
Set Create New Volume to Yes.
Set the Volume Size to at least the image’s minimum disk requirement.
Set Delete Volume on Instance Delete based on your retention policy.

Setting	Recommendation
Create New Volume	`Yes` — creates a persistent boot volume
Volume Size	≥ image minimum disk size (shown in image metadata)
Delete Volume on Instance Delete	`No` for production; `Yes` for ephemeral workloads

Complete and launch

Complete the remaining tabs (Flavor, Networks, Security Groups, Key Pair) and click Launch Instance.

After launch, navigate to Project → Volumes → Volumes to confirm the boot volume was created and is in In-use status.

Authenticate

Source your credentials file to authenticate with the Xloud platform:

Load credentials

source admin-openrc.sh

Download the OpenRC file from Xloud Dashboard → Project → API Access → Download OpenStack RC File.

Create a bootable volume from an image

Create a bootable volume

openstack volume create \
  --image <IMAGE_ID_OR_NAME> \
  --size 50 \
  --bootable \
  my-boot-volume

Wait for the volume to reach available status:

Check volume status

openstack volume show my-boot-volume -c status

Launch the instance from the volume

Boot from the existing volume

openstack server create \
  --volume my-boot-volume \
  --flavor <FLAVOR_NAME> \
  --network <NETWORK_ID_OR_NAME> \
  --key-name <KEYPAIR_NAME> \
  my-instance

When using --volume, the volume becomes the boot device directly. Do not also specify --image — that would create a second, conflicting boot source.

Attach Additional Volumes at Launch

Attach pre-existing data volumes when creating an instance to have formatted storage available immediately after boot.

Dashboard
CLI

The Dashboard does not expose the full BDM --block-device API at launch time for additional volumes. Attach pre-existing volumes after launch:Navigate to Project → Volumes → Volumes, find the target volume, and select Manage Attachments → Attach to Instance.

For complex BDM configurations (multiple volumes at launch, specific boot index control), use the CLI which provides full --block-device parameter support.

Launch with an additional data volume attached

openstack server create \
  --image <IMAGE_ID_OR_NAME> \
  --flavor <FLAVOR_NAME> \
  --network <NETWORK_ID_OR_NAME> \
  --key-name <KEYPAIR_NAME> \
  --block-device source_type=volume,uuid=<VOLUME_ID>,destination_type=volume,boot_index=1 \
  my-instance

The additional volume appears inside the instance as a secondary block device (e.g., /dev/vdb). Format and mount it before use:

Format and mount the attached volume (inside the instance)

sudo mkfs.ext4 /dev/vdb
sudo mkdir -p /data
sudo mount /dev/vdb /data
echo '/dev/vdb /data ext4 defaults 0 2' | sudo tee -a /etc/fstab

Only format a volume if it contains no data. Formatting overwrites all existing content on the device.

Ephemeral Disk Configuration

Ephemeral disks are temporary storage included in certain flavors. They exist only for the lifetime of the instance and are reset or removed on rebuild, resize, or termination.

Property	Value
Device path	`/dev/vdb` (first ephemeral); `/dev/vdc` if a persistent volume is also attached
Persistence	Deleted when the instance is terminated or rebuilt
Use case	Scratch space, temporary build artifacts, swap
Flavor control	Ephemeral disk size is defined by the flavor, not configurable at launch

Do not store persistent data on ephemeral disks. Use Xloud Block Storage volumes or Xloud Object Storage for durable workloads that must survive instance termination.

BDM Scenarios Summary

Production workload — persistent root disk

Recommended configuration: Boot from volume with delete_on_termination=false. The root disk survives instance deletion, enabling backup, snapshot, and re-attachment workflows.

CLI: launch with persistent boot volume

openstack server create \
  --volume <BOOTABLE_VOLUME_ID> \
  --flavor <FLAVOR> \
  --network <NETWORK> \
  my-prod-instance

Stateless workload — ephemeral root disk

Recommended configuration: Boot from image with delete_on_termination=true. Suitable for auto-scaling groups, CI runners, or stateless app tiers where instances are disposable.

CLI: launch with ephemeral root (deleted on terminate)

openstack server create \
  --image <IMAGE> \
  --flavor <FLAVOR> \
  --network <NETWORK> \
  --block-device source_type=image,uuid=<IMAGE_ID>,destination_type=local,boot_index=0,delete_on_termination=true \
  my-stateless-instance

Database tier — separate data volume

Recommended configuration: Boot from volume (OS) + separate data volume (database files). This separates the OS lifecycle from the data lifecycle — terminate and rebuild the OS volume while the data volume persists.

CLI: launch with separate data volume

openstack server create \
  --volume <OS_VOLUME_ID> \
  --flavor <FLAVOR> \
  --network <NETWORK> \
  --block-device source_type=volume,uuid=<DATA_VOLUME_ID>,destination_type=volume,boot_index=1 \
  my-db-instance

Next Steps

Xloud Block Storage

Create, manage, and snapshot persistent block storage volumes

Launch an Instance

Full instance launch walkthrough including boot source and volume configuration

Rescue an Instance

Mount and repair volumes when an instance fails to boot

Compute User Guide

Overview of all compute operations and instance lifecycle management

Core Services

Other Services

Block Device Mapping

Overview

BDM Attributes Reference

Boot from Volume

Open the Launch Instance dialog

Configure the boot source

Complete and launch

Authenticate

Create a bootable volume from an image

Launch the instance from the volume

Attach Additional Volumes at Launch

Ephemeral Disk Configuration

BDM Scenarios Summary

Next Steps

Xloud Block Storage

Launch an Instance

Rescue an Instance

Compute User Guide

Core Services

Other Services

​Overview

​BDM Attributes Reference

​Boot from Volume

Open the Launch Instance dialog

Configure the boot source

Complete and launch

Authenticate

Create a bootable volume from an image

Launch the instance from the volume

​Attach Additional Volumes at Launch

​Ephemeral Disk Configuration

​BDM Scenarios Summary

​Next Steps

Xloud Block Storage

Launch an Instance

Rescue an Instance

Compute User Guide

Overview

BDM Attributes Reference

Boot from Volume

Attach Additional Volumes at Launch

Ephemeral Disk Configuration

BDM Scenarios Summary

Next Steps