Kvindo™ Cloud Docs
A Volume is a block storage device that provides persistent disk space for VMs. Volumes exist independently of VMs and can be attached, detached, and re-attached as needed. A volume seeded with an OS image can serve as a VM's boot disk.
• Size — storage capacity in GiB; for an attached ext4 volume the guest partition/filesystem now grows automatically along with it (see Resizing below for what's still manual)
• OS image — an optional OS image identifier (osImageId) used to seed the volume; a volume seeded this way can boot a VM
• Offer — the disk type/tier (offerId); see the console for the catalog
• Attachment — the VM a volume is currently connected to (see Volume Attachment)
A volume persists after a VM is deleted; it must be deleted explicitly.
| UI Name | API / kc name | Terraform name | Optional | Format | Default | Is read only | Description |
|---|---|---|---|---|---|---|---|
| Hosting Provider | spec.hostingProviderId |
spec.hosting_provider_id |
No | ULID — references a Hosting Provider | — | No | Provider on which the volume is provisioned; run kc get provider for the options |
| OS Image | spec.osImageId |
spec.os_image_id |
Yes | string (nullable) | — | No | OS image identifier used to seed the volume (e.g. 200 = Ubuntu Server 24.04 LTS); see Console → Compute → Images. Omit for a blank data disk. Mutually exclusive with imageId |
| Offer | spec.offerId |
spec.offer_id |
No | string | — | No | Disk offer / type id — there is no server-side default, so pass one explicitly (gp3-750 is the cheapest); see Console → Volumes |
| Size (GiB) | spec.sizeGiB |
spec.size_gib |
No | integer | — | No | Volume capacity in GiB |
| Image | spec.imageId |
spec.image_id |
Yes | ULID (nullable) — references an Image | — | No | Restore the volume from an existing Image — the Image must have been captured from a Volume, not from a VM. Mutually exclusive with osImageId |
spec.sizeGiB on an attached volume now also grows
the guest partition and ext4 filesystem automatically, right after the resize — no manual
steps needed for the common case (partition 1, ext4, an unmodified standard image).
This is best-effort and silently does nothing if it doesn't apply — it never fails the resize itself. You still need the manual steps below if: the volume is detached (not attached to a VM) at resize time; the filesystem isn't ext4 (LVM, software RAID, disk encryption, XFS/btrfs, Windows guests); or you've repartitioned the volume yourself so the data partition isn't partition 1.
Run lsblk -f to find your actual device (and confirm FSTYPE shows ext4)
and substitute it below — /dev/vda is typically the boot disk, additional volumes
are /dev/vdb, /dev/vdc, etc. A device with a numbered child
(vda → vda1) is partitioned; one with no children is not. If your
root filesystem isn't on partition 1 (check with df /), substitute that number
too, e.g. growpart /dev/vda 2. The target filesystem must already be mounted —
check with mount | grep vdb and mount it first if not.
Partitioned disks (most boot disks, GPT)
Unpartitioned disks (plain data volumes)
Both commands are safe to re-run. Afterward, check lsblk / df -h to
confirm the new size shows up.
Terraform
Python SDK
kc CLI
Examples
More in this section