This is an old revision of the document!
Table of Contents
EVE-OS / ZEDEDA Application Volumes
Covers: what a volume is, what has to be configured in the GUI vs Terraform, how to deploy an app with a volume, and how to grow a volume after deployment.
Sources: lf-edge/eve, zededa/zedcloud Terraform provider docs, ZEDEDA Help Center (Storage Overview, Manage an Edge Application Instance, ZCLI volume-instance docs).
1. What a volume is
A volume instance is the storage object EVE-OS attaches to an app instance as a drive. It backs one of:
- The app's rootfs / OS disk (built from a Content Tree / image)
- A blank data disk for app data (drive type
HDD_EMPTY) - A shared/persistent data volume that can outlive the app instance or be shared between app instances on the same node
A volume can be:
- Implicit — created automatically as part of an app instance's drive list (defined inline on the app manifest)
- Explicit — created ahead of time as its own object (
zcli volume-instance create) and then referenced by label when the app is deployed
Underlying storage is a qcow2 file (ext4 persist) or a zvol (ZFS persist), depending on how the edge node's /persist partition was provisioned at install time — see the separate EVE-OS Partitioning / ZFS wiki page for that layer. Volumes live inside whichever persist backend the node has.
2. Key fields
| Field | Where it shows up | What it does |
|---|---|---|
Drive Type (drvtype) | GUI Drives pane / TF drvtype | CDROM, HDD, NET, HDD_EMPTY. HDD_EMPTY allocates a blank disk of maxsize. |
Max Size (maxsize / maxsizebytes) | GUI Drives pane “Max Size” / TF maxsize | Capacity ceiling for the drive. For an image-backed drive this must be >= the image size; the difference is usable growable space. |
Preserve (preserve) | GUI Drives pane “Preserve” | Whether this drive's data survives a purge/refresh of the app instance, vs. being rebuilt from the source image. |
Allow Storage Resize (allow_storage_resize / allowStorageResize) | App instance level, GUI/zcli/TF | Must be enabled before an existing app instance's drive size can be increased. Default: false. |
Volume Label (volumelabel) | GUI Drives pane / TF | References a pre-created (explicit) volume instance instead of an inline drive definition. |
Mount Path (mountpath) | GUI Drives pane / TF | Path inside the app where the drive is mounted. Empty or / defines the rootfs. |
3. What's required to configure — GUI vs Terraform
GUI
- Volume instances can be created standalone: Edge Node > Storage > Volume Instances > Add, or created implicitly while adding a drive to an app instance.
- On the app instance's Drives pane, define per drive: Drive Type, Image (if any), Mount Path, Max Size, Preserve, Encrypted, and (for explicit volumes) Volume Label.
- Editing Drives on an existing app instance triggers a Purge & Update — the app purges and comes back online. Data on that drive is wiped unless Preserve was set.
Terraform (zededa/zedcloud provider)
- Resource:
zedcloud_application_instance(orzedcloud_deploymentfor policy-driven rollout). - Drive block fields:
drvtype,maxsize,preserve,mountpath,imagename/imvolname/mvolname,volumelabel. - App-instance-level field:
allow_storage_resize(bool, default false) — must betrueto permit a latermaxsizechange to apply. - Standalone volume instances can also be managed as their own resource/data source (
zedcloud_volume_instancefamily) and referenced by label from the app instance.
ZCLI
- Explicit volume:
zcli volume-instance create <name> –volume-type=<type> –project=<project> (–edge-node=<node> | –edge-node-cluster=<cluster>) –size=<size> –access-mode=<mode> - Update:
zcli volume-instance update <name> [–title=…] [–description=…] - App-instance-level resize permission is passed the same way as the GUI/TF flag, camelCase in JSON:
“allowStorageResize”: true
4. Step-by-step: Deploy an app with a volume
Via GUI
- Go to Edge Applications > Marketplace, select or create the edge app.
- (Optional, for a shared/persistent volume) Go to Edge Node > Storage > Volume Instances > Add and create the volume instance ahead of time. Note the label.
- Deploy the app: Edge Applications > Deploy, pick the target edge node.
- On the Drives pane:
- Add a drive for the rootfs (Drive Type
HDD, pointed at the app image). - Add a second drive for data: Drive Type
HDD_EMPTY, set Max Size, set Preserve if the data should survive future purges, and either let EVE create it implicitly or set Volume Label to the volume instance created in step 2.
- Complete networking/resources panes as normal and click Deploy.
- Confirm in Edge Node > App Instances that the instance reaches
RUNNINGand the drive shows the expected size under app instance details.
Via Terraform
resource "zedcloud_application_instance" "example" {
name = "my-app-instance"
app_id = zedcloud_application.example.id
device_id = data.zedcloud_edgenode.target.id
project_id = data.zedcloud_project.example.id
drives {
drvtype = "HDD"
imagename = "my-app-image"
mountpath = "/"
}
drives {
drvtype = "HDD_EMPTY"
maxsize = "10737418240" # 10 GiB, in bytes
preserve = true
mountpath = "/data"
}
allow_storage_resize = true
}
terraform plan/terraform apply.- Verify state:
terraform state show zedcloud_application_instance.exampleor check the GUI app instance detail page.
5. Step-by-step: Grow a volume
Important: this is not a live/hot resize. Editing a drive on an existing app instance triggers a Purge & Update — the app purges and restarts. Data on that drive is lost unless preserve is set on it.
Via GUI
- Confirm the drive you're growing has Preserve set (if you need to keep its data).
- Go to Edge Applications > App Instances, select the instance, Edit.
- If not already enabled, enable Allow Storage Resize at the app instance level.
- On the Drives pane, raise the Max Size field for the target drive.
- Save. The GUI will show a Purge and update notification — confirm it.
- Wait for the app instance to purge and come back
RUNNING. - Log into the guest and grow the filesystem to use the new space (see step below — EVE resizes the backing volume, not the guest's partition/fs).
Via Terraform
resource "zedcloud_application_instance" "example" {
# ...unchanged config...
drives {
drvtype = "HDD_EMPTY"
maxsize = "21474836480" # was 10 GiB, now 20 GiB
preserve = true
mountpath = "/data"
}
allow_storage_resize = true # must be true BEFORE the maxsize change is allowed to apply
}
terraform apply. Ifallow_storage_resizewasfalseon the last-applied state, apply that change first, then apply themaxsizechange (or in the same apply if the provider allows it — verify against current provider version behavior before assuming ordering).- Confirm the app instance purges and comes back up.
Guest-side step (both paths)
EVE enlarges the backing volume (qcow2/zvol); it does not grow the guest's partition or filesystem automatically. After the app instance comes back up:
- Linux ext4:
growpart /dev/xxx Nthenresize2fs /dev/xxxN - Linux xfs:
growpartthenxfs_growfs <mountpoint> - Windows: Disk Management > right-click volume > Extend Volume
6. Open questions / to verify before relying on this in production
- Exact ordering requirement between setting
allow_storage_resize=trueand applying amaxsizechange in a single Terraform apply — not confirmed from docs, test on a non-prod app instance first. - Whether any current EVE-OS version auto-grows the guest filesystem on boot after a resize (e.g., via cloud-init growpart module) — not confirmed; assume manual step is required unless verified for your specific image.
- This applies to app instance drives only. It does not expand the underlying
/persiststorage pool (ext4 disk or ZFS pool) — see the separate Partitioning/ZFS page for that, which is a install-time/reinstall operation, not a controller-driven one.
