Differences

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

--- zededa:eve-app-volumes [2026/07/06 18:52] – 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''. For a **container-type app** (''app_type = "APP_TYPE_CONTAINER"''), setting ''mountpath'' causes EVE to automatically mount that volume's filesystem at that path inside the running container — no manual mount step needed in the guest, the same way a Docker ''-v host:/container'' bind mount works. The container just finds ''/data'' already populated and writable at start. This is distinct from a raw VM block device (see ''HDD_EMPTY'' below and the guest-side step in section 5), where the guest OS gets a bare block device and has to partition/format/mount it itself — ''mountpath'' auto-mounting is a container-app convenience, not something that applies the same way to a classic VM's raw disk. |
+| ''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 220: / Line 220: @@
 ==== Guest-side step ====
-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:
+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 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:
+  * **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.
-    * Linux ext4: ''growpart /dev/xxx N'' then ''resize2fs /dev/xxxN''
+  * **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."
-    * Linux xfs: ''growpart'' then ''xfs_growfs <mountpoint>''
-    * Windows: Disk Management > right-click volume > Extend Volume
+Reference commands if a manual resize turns out to be needed:
-  * **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."
+  * 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
 ===== 6. Other use case: HDD_EMPTY (blank data disk, no attached content) =====