Managing Disks and Snapshots


Disks are persistent block-storage volumes that can be managed independently from VM instances. Their content is however accessible only when they are attached to a VM. When a VM is deleted, its disks are detached and remain intact until they are explicitly deleted.

Disks can be provisioned from images or snapshots made on the Oxide rack, or external images in RAW format. Regardless of the source, boot disks must have an installed operating system. You can also create blank disks to provide additional or partitioned VM storage. In summary, the options for making a disk are:

  • blank: creates an empty disk formatted with the block-size specified; the available options are 512, 2048, and 4096 bytes

  • importing_blocks: creates an empty disk that is ready for data import from an external file

  • snapshot: clones from an existing snapshot in the same project

  • image: clones from an existing image in the same project or a shared image in the silo

Other required attributes for disk provisioning are: name, description, and total size. Disk naming is subject to the same RFC 1035 restrictions as instance and image names.

Disk States during Provisioning

Disk provisioning may involve multiple steps depending on the method of creation. For this reason, disks may assume different states and the actions allowed also vary based on the states they are in.

Disk Provisioning State Transition

The states marked by an * are transient states. In most cases, once a disk has been successfully created, the disk status is set to detached immediately. The only exception is making a disk by importing blocks because the process involves asynchronous client interactions.

Disks created through file import must go through several state transitions as shown in the diagram above:

  1. When the disk is first created, it is set to import_ready to await data write requests.

  2. The client controls how to chunk up the file and when to send the data chunks.

    1. Data writes begin when the client invokes the bulk-write-start API call.

    2. Once the disk is in the importing_from_bulk_writes state, the client can issue multiple bulk-write API calls to send the base64-encoded data chunks along with the byte offset.

    3. When all the chunks have been imported, the client signifies the end of data import with a bulk-write-stop API call, putting the disk back to the import_ready state.

    4. If the data import is paused or fails for any reason, the client can resume or retry bulk writes by specifying the appropriate offset.

  3. When disk import is completed, the client invokes the finalize API call to put the disk to detached state. The action also includes an option to take a snapshot of the disk.

To abandon a disk import and remove a disk with incomplete data, you can use the same bulk-write-stop and finalize commands to bring the disk to import_ready and detached states respectively. Once the disk has been detached from writes, you will be able to delete it.

Disk States after Provisioning

Newly provisioned disks are set to the detached state and can be attached to an existing VM or a new instance. Each disk may only be attached to one VM at a time.

To move a disk from one VM to another, the instances involved must both be shut down for the disk to be detached and attached.

Disks can only be deleted when they are detached. Destroyed disks are irrecoverable and are not accessible in the web console or API.

Disk Lifecycle State Transition

* denotes transient states

Data Encryption

Server-side encryption is enabled by default and cannot be disabled. All data stored at rest in the physical disks are double encrypted at both the volume and ZFS dataset levels.


One or more snapshots can be created for an attached or detached disk. Although snapshots for the same disk are stored incrementally to reduce storage space consumption, they can be retained or removed independently.

Because snapshots are different versions of a disk, they can be used to roll back or forward a VM’s on-disk storage state by simply swapping out the current disk with another disk with an older or newer snapshot. A VM can also be cloned by creating a new VM with disks that are made from snapshots of the disks of the original VM. The use of snapshots in these scenarios is however limited to the data on disk. States and data in memory are not reinstated or replicated.

A disk snapshot captures only the content of the disk involved. Snapshots does not include any data in memory or transit, nor the states of the running VM and network devices associated with the disk.

Making Custom Images and Data Backup

Here are some example workflows for using images and snapshots with VM instances.

Example 1: Prepare a reusable Linux application image from scratch

  1. Create a boot disk by importing a Linux distro RAW file.

  2. Create a VM instance with the boot disk attached.

  3. Install applications along with any necessary prerequisites, tools, and configurations on the VM.

  4. Shut down the VM instance.

  5. Detach the boot disk from the VM instance.

  6. Create a snapshot of the boot disk.

  7. Create a new image from the above disk snapshot as the application image.

Example 2: Backup/restore database using snapshots

  1. Create a disk with an installed OS image as the boot disk.

  2. Create a blank disk as a data volume to be used by the database.

  3. Create a VM instance that is attached to the boot disk (primary) and the blank disk (secondary).

  4. Install the database application along with any necessary prerequisites, tools, and configurations on the VM, with data storage configured to go into some /data folder in the secondary disk.

  5. Create backup snapshots of the data/secondary disk as needed when the VM is in a stopped state.

To restore from an older database snapshot:

  1. Create a disk from the desired snapshot.

  2. Shut down the database application VM.

  3. Detach the existing data disk from the VM and attach the disk created above.

  4. Start the database application.

Disks created from images are not physically connected to the image filesystem records. Similarly, images created from snapshots are not dependent on their presence afterwards. In other words, images, snapshots, and disks can be deleted without affecting each other.
Last updated