Volume attachments and device identity
Track attachment identity, guest device discovery, and safe writer transitions.
An attachment binds a volume to a droplet and records its device identity and write ownership. The volume and attachment have separate IDs and lifecycles.
Attach and discover
Open Volume → Attachments → Attach and choose a stopped droplet or a guest that supports hot attachment. The volume must belong to the same project and region. Infra checks storage reachability from the observed execution node.
The accepted request creates an attachment ID before the device is necessarily
visible inside the guest. Read the attachment's observed state and wait for its
operation. An attachment in attaching must not be treated as a mounted filesystem.
Infra publishes a stable serial for the virtual disk. Inside Linux, inspect the
serial and /dev/disk/by-id links instead of persisting the transient name
/dev/vdb. Removing and reattaching the same volume creates a new attachment;
automation must reconcile its recorded attachment ID.
Root and data roles
The root attachment participates in the droplet's boot configuration. It cannot be detached from a running guest. Data attachments can be hot-removed only when the hypervisor and guest support removal and application writes have stopped.
A data volume does not become the root disk merely because it contains a bootable filesystem. Replacing a root disk is an explicit stopped operation with image and firmware validation. The previous root volume remains retained unless an operator separately deletes it.
Writable ownership
A writable volume supports one active droplet attachment. The control plane
records the intended owner; the storage path enforces its active writer lease.
A recorded detaching state does not prove that an old writer lost access.
During migration, the attachment ID stays stable while execution ownership moves. The destination cannot begin independent writes until the migration commit establishes its ownership. A failed control connection can therefore keep the operation reconciling without allowing a second writer.
Clean detach
Stop the application, flush its data, unmount the filesystem, and submit detach.
Check the mount state inside the guest rather than assuming a completed application
shutdown unmounted every filesystem. Wait for detached before attaching elsewhere.
If guest removal succeeds but storage cleanup fails, the operation identifies the retained lease or path. Do not create a new attachment against an unresolved writer. Restore connectivity or complete the approved fencing procedure.
Stale attachments
Deleting a droplet removes its attachment resources after shutdown and cleanup.
A historical attachment ID remains in operations and audit history but returns
404 from the live attachment endpoint after removal.
Use the Volume API for conditional attachment requests, volume encryption for key dependencies, and node fencing for unreachable sources.