Differences

This shows you the differences between two versions of the page.

--- zededa:eve-app-volumes [2026/07/06 18:49] – mc
+++ zededa:eve-app-volumes [2026/07/06 18:53] (current) – mc
@@ Line 46: / Line 46: @@
 | ''imageformat'' | ''CONTAINER'' for the app's own OCI image; ''QCOW2'' for an attached persistent block-storage volume. |
 | ''drvtype'' | ''HDD'' confirmed for a persistent data disk. (''HDD_EMPTY'', ''CDROM'', ''NET'' — see section 6 and drive-type discussion earlier in this doc's history; not all re-confirmed against a real example yet.) |
-| ''mountpath'' | Path inside the app, e.g. ''/data''. |
+| ''mountpath'' | Path inside the app, e.g. ''/data''. Setting ''mountpath'' causes EVE to automatically mount that volume at that path inside the guest — this applies to **both container-type and VM-type apps**, not just containers. The guest doesn't need a manual mount step to get the volume attached at that path; EVE handles it. (The exact guest-side mechanism for VM apps — e.g. whether it's cloud-init-driven, an fstab entry EVE injects, or a guest agent — isn't confirmed from source; noted as an open item in section 7.) This is separate from whether the *filesystem on that volume* needs formatting on first use, or resizing after a ''maxsize'' change — see the guest-side step in section 5. |
 | ''cleartext'' | Inverted, same convention as the standalone volume instance — ''false'' means encrypted. |
 | ''ignorepurge'' | Real, distinct field from ''preserve'' — both appear together in real examples (''ignorepurge = true'', ''preserve = true''). Exact semantic split between the two is still not confirmed from proto-level source; treat as "there are two separate purge-related knobs here, not one," rather than assuming they're synonyms. |
@@ Line 218: / Line 218: @@
 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.
-==== Guest-side step (either path) ====
+==== Guest-side step ====
-Raising the size enlarges the backing storage object (whatever ''volumemgr'' made it — see companion page); it does **not** grow the guest's partition or filesystem automatically. After the app instance comes back up:
+Mounting the volume at ''mountpath'' is automatic for both VM and container apps (see section 2). What is **not** automatic is growing the filesystem living on that volume after a ''maxsize'' increase:
+  * **Raw/unformatted disk (no filesystem yet, e.g. a fresh ''HDD_EMPTY'')**: still needs an initial partition/format the first time it's used, regardless of app type — ''mountpath'' auto-mounts the device, it doesn't format it.
+  * **Existing filesystem, size increased via ''maxsize''**: whether the filesystem auto-expands to fill the new space, or needs an explicit resize, is **not confirmed** either way — for a VM app this would normally be the classic ''growpart''/''resize2fs''/''xfs_growfs'' pattern run inside the guest; for a container app it may depend on how EVE re-presents the resized volume on next purge/redeploy. Verify on a test app instance by growing ''maxsize'', redeploying, and checking available space at the mount path before assuming either "just works."
+Reference commands if a manual resize turns out to be needed:
   * Linux ext4: ''growpart /dev/xxx N'' then ''resize2fs /dev/xxxN''
   * Linux xfs: ''growpart'' then ''xfs_growfs <mountpoint>''