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. Primary examples use an image-backed HDD drive; HDD_EMPTY is covered as a separate use case at the end.

This page stays at the controller/app-instance config layer — the fields you set in the GUI, Terraform, or zcli. For what actually happens on the storage backend underneath (qcow2 vs. zvol, pool RAID vs. per-app resize), see the companion page: EVE-OS Volume Provisioning: Pool Layer vs. Per-App Layer.

Sources: lf-edge/eve, zededa/zedcloud Terraform provider docs, ZEDEDA Help Center, and real working Terraform (confirmed against actual zedcloud_application / zedcloud_volume_instance resources, not just provider doc snippets).

A volume/drive is a storage object attached to an app. It backs one of:

• The app's rootfs / OS disk (built from a Content Tree / image) — drive type HDD
• A blank data disk for app data — drive type HDD_EMPTY
• A shared/persistent data volume that can outlive the app, created standalone and attached by reference

A volume can be:

• Implicit — an entry in the images list inside the app's manifest block, defined inline, tied to that app
• Explicit — a standalone zedcloud_volume_instance resource (or GUI: Library > Volume Instances > +), created independently, then attached to an app via volumelabel referencing the standalone volume's label

Important layering note: everything on this page — maxsize, preserve, ignorepurge, drvtype — is a controller-side config object. It says nothing about how the volume is physically stored. EVE's volumemgr agent on the node reads this config and decides how to realize it on whatever persist backend the node has (ext4 or ZFS). That translation step is a completely separate layer — see the companion page.

Created independently of any app, targets an edge node or cluster directly.

This is the actual, confirmed schema — nested inside manifest { }, as a repeated images { } block, not a top-level drives block as earlier drafts of this page assumed.

• user_defined_version (on zedcloud_application) — a real example carries the comment *“bump to force a new app version after adding the :1080→:80 portmap ACL”*. This strongly implies this is the mechanism that pushes a manifest change (including an images block edit like a maxsize bump) out to the running app — bump the version string, apply, and the controller treats it as a new app version to roll out. This replaces an earlier, unconfirmed guess on this page about an allow_storage_resize flag gating resize — that field does not appear in any real example provided and should be treated as unverified/likely incorrect unless you find it in an actual working config.

• Standalone volume instances: Library > Volume Instances > + (Add Volume Instance). Set Type (Content Tree or Block Storage), Access Mode, target Edge Node, and either Image (Content Tree) or Max Storage Size (Block Storage).
• Implicit volumes are created inline while adding a drive to an app instance instead — no separate object.
• On the app's Drives pane (GUI's view into the manifest.images list), define per drive: Drive Type, Image or Volume Label, Mount Path, Max Size, Preserve.
• Editing Drives on an existing app instance triggers a Purge & Update in the GUI — the app purges and comes back online. Data on that drive is wiped unless Preserve was set.

• Standalone volume: zedcloud_volume_instance — see field table above.
• App + attached volume: zedcloud_application, with a manifest { images { … } } block per drive. See section 4 for a full real example.
• To attach a standalone volume instance to an app, reference its label via volumelabel in one of the app's images entries — do not redeclare size/type there, those live on the volume instance itself.
• Bump user_defined_version on the zedcloud_application resource to push out a manifest change.

• 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=…]

This is the real, confirmed pattern: a standalone zedcloud_volume_instance (persistent, survives app redeploys) attached to an app's second images entry by volumelabel, alongside the app's own container image as the first entry.

# 1. Standalone persistent volume, targeting a specific edge node
resource "zedcloud_volume_instance" "tf_demo_vol1_cont_persist" {
  device_id  = zedcloud_edgenode.demo_en_onlogic_cl250.id  # Edge Node ID
  accessmode = "VOLUME_INSTANCE_ACCESS_MODE_READWRITE"
  cleartext  = false
  label      = "adv-vol1-cont-persist"
  name       = "adv-vol1-cont-persist"
  size_bytes = 1073741824   # 1 GiB
  title      = "adv-vol1-persist"
  type       = "VOLUME_INSTANCE_TYPE_BLOCKSTORAGE"
 
  lifecycle {
    ignore_changes = [device_id]
  }
}
 
# 2. App that attaches the volume above as its second drive
resource "zedcloud_application" "tf_nginx_app_1" {
  name     = "TF-STND-NGINX-APP-1"
  title    = "TF-STND-NGINX-APP-1"
  networks = 1
  manifest {
    ac_kind    = "VMManifest"
    ac_version = "1.2.0"
    name       = "TF-NGINX-APP-1"
    owner {
      user    = "Manny"
      company = "Zededa"
      website = "www.zededa.com"
      email   = "manny@zededa.com"
    }
    desc {
      app_category = "APP_CATEGORY_CLOUD_APPLICATION"
      category     = "APP_CATEGORY_UNSPECIFIED"
      logo = {
        url = "https://nginx.org/img/nginx_logo.svg"
      }
    }
    images {
      # first drive: the app's own container image
      imagename   = zedcloud_image.demo_nginx_alpine.name
      cleartext   = false
      ignorepurge = true
      imageformat = "CONTAINER"
    }
    images {
      # second drive: attach the standalone persistent volume from above
      volumelabel = zedcloud_volume_instance.tf_demo_vol1_cont_persist.label
      imageformat = "QCOW2"
      mountpath   = "/data"
      cleartext   = false
      drvtype     = "HDD"
      ignorepurge = true
      preserve    = true
      maxsize     = 1073741824
      target      = "Disk"
    }
    interfaces {
      name         = "eth0"
      type         = "ip"
      directattach = false
      privateip    = false
      acls {
        matches {
          type  = "ip"
          value = "0.0.0.0/0"
        }
      }
    }
    vmmode    = "HV_PV"
    enablevnc = true
    resources {
      name  = "resourceType"
      value = "custom"
    }
    resources {
      name  = "cpus"
      value = 2
    }
    resources {
      name  = "memory"
      value = 2097152
    }
    configuration {
      custom_config {
        add      = true
        name     = "cloud-config"
        override = true
        template = ""
      }
    }
    app_type            = "APP_TYPE_CONTAINER"
    deployment_type     = "DEPLOYMENT_TYPE_STAND_ALONE"
    cpu_pinning_enabled = false
  }
  user_defined_version = "1"
  origin_type          = "ORIGIN_LOCAL"
  project_access_list  = []
}

1. terraform plan / terraform apply.
2. Confirm in the GUI that the app instance reaches RUNNING and the second drive shows the persistent volume attached at /data.

Important: this is not a live/hot resize. Applying a manifest change that alters an images entry triggers a purge/redeploy of the app. Data on that drive is lost unless preserve/ignorepurge are set appropriately on that entry.

1. Raise maxsize on the relevant images block (or size_bytes on the standalone zedcloud_volume_instance, if the volume is standalone rather than inline).
2. Bump user_defined_version on the zedcloud_application resource — this is the confirmed mechanism (see the real example's own comment: *“bump to force a new app version”*) for pushing the manifest change out.
3. terraform apply.
4. Confirm the app redeploys and the drive reflects the new size.

images {
  volumelabel = zedcloud_volume_instance.tf_demo_vol1_cont_persist.label
  imageformat = "QCOW2"
  mountpath   = "/data"
  cleartext   = false
  drvtype     = "HDD"
  ignorepurge = true
  preserve    = true
  maxsize     = 2147483648   # was 1 GiB, now 2 GiB
  target      = "Disk"
}
# ...
user_defined_version = "2"   # bumped from "1" to push this change out

If the volume is instead a standalone zedcloud_volume_instance (not inline in the app's images list), raise size_bytes on that resource directly and apply — no app-side version bump needed in that case, since the volume object is independent of the app manifest.

Raising the size enlarges the backing storage object (whatever volumemgr made it — see companion page); it does not automatically grow the filesystem living on top of it. What “growing the filesystem” requires depends on how the drive is presented:

• Raw VM block device (e.g. an HDD_EMPTY disk on a classic VM app): the guest sees a bare block device and must run the usual in-guest resize itself:
  • Linux ext4: growpart /dev/xxx N then resize2fs /dev/xxxN
  • Linux xfs: growpart then xfs_growfs <mountpoint>
  • Windows: Disk Management > right-click volume > Extend Volume
• Container-mounted volume (mountpath on a container-type app, like the /data examples in section 4): since EVE auto-mounts the volume's filesystem into the container rather than exposing a raw block device, whether the underlying filesystem auto-expands to fill the new maxsize, or needs an equivalent resize step triggered by EVE/containerd on the next purge/redeploy, is not confirmed. Treat as an open question — verify on a test app instance by growing maxsize, redeploying, and checking available space at /data from inside the container before assuming it “just works.”

HDD_EMPTY is the drive-type equivalent of a standalone VOLUME_INSTANCE_TYPE_BLOCKSTORAGE volume, but declared inline in an app's images block instead of as a standalone object — no image, no content tree, no volumelabel reference, just a blank disk sized by maxsize.

• No imagename and no volumelabel — the entry is purely drvtype = “HDD_EMPTY” plus maxsize.
• Arrives to the guest as a raw, unformatted block device; the guest OS (or first-boot cloud-init) has to partition and format it.
• Use this over a standalone volume instance when the data disk is specific to one app and doesn't need to be managed as its own independent object (e.g. reused across app versions, or attached to a different app later).

• Exact semantic split between ignorepurge and preserve — both are confirmed real, distinct fields that appear together in working examples, but the precise difference in behavior between them is not confirmed from proto-level source.
• Whether allow_storage_resize is a real field at all — it does not appear in any real example seen so far. Earlier drafts of this page asserted it existed based on generic provider-doc search snippets; treat that as unverified/likely wrong unless confirmed against an actual working resource.
• Full set of valid values for target on an images block — only “Disk” confirmed.
• Full set of valid type/accessmode enum values on zedcloud_volume_instance beyond VOLUME_INSTANCE_TYPE_BLOCKSTORAGE and VOLUME_INSTANCE_ACCESS_MODE_READWRITE.
• 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.
• How maxsize/size_bytes actually gets realized on disk (qcow2 vs. per-app zvol, thin vs. thick) — different layer than anything on this page. See EVE-OS Volume Provisioning: Pool Layer vs. Per-App Layer.
• This page is entirely about app-attached volumes. It does not cover the underlying /persist storage pool (ext4 disk or ZFS pool, RAID level) — that is an install-time/reinstall decision made via grub.cfg, not a controller-driven one. Covered on the EVE-OS Partitioning / ZFS wiki page.