Skip to content

Clarification on OverlayFS Configuration for Firecracker VMs via Flintlock gRPC API #1057

@andupotorac

Description

@andupotorac

Describe the solution you'd like:
We are working on integrating Flintlock (via its gRPC API) to manage Firecracker microVMs. Our goal is to optimize VM startup times and resource usage by employing an OverlayFS setup where:

  1. The base root filesystem is a read-only SquashFS image (e.g., base.squashfs).
  2. The writable upper layer for session-specific changes is backed by tmpfs on the host.

We've reviewed the documentation and I'm not sure if Flintlock supports OverlayFS. Also, we need to clarify the exact mechanism for instructing Flintlock to use this specific layered approach when creating a new Firecracker microVM through its gRPC interface

Why do you want this feature:

Specifically, our question is:
When configuring a Firecracker microVM to use a SquashFS base image as a lower directory and a tmpfs-backed upper directory for OverlayFS:

A) Does Flintlock itself handle the mount -t overlay ... operation?

If so, how do we specify the paths to the read-only SquashFS file (lowerdir), the pre-created tmpfs path for the upperdir on the host, and the workdir path on the host via the Flintlock gRPC API? Are there specific fields in the MicroVMSpec (or elsewhere) for these distinct OverlayFS directories?

B) Or, does Flintlock expect the host system to have already mounted the OverlayFS?

If this is the case, would we then provide Flintlock with a single path to this pre-existing OverlayFS mount point as the VM's root_fs?

Could you please point us to the relevant API fields, configuration examples, or documentation that details how to correctly pass these parameters to Flintlock to achieve this SquashFS + tmpfs OverlayFS setup? Any insights into best practices for managing the host-side tmpfs directories (upperdir, workdir) in conjunction with Flintlock would also be highly appreciated.

Thanks for your help!

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/featureNew feature or requestlifecycle/staleDenotes an issue or PR has remained open with no activity and has become stale.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions