feat(firecracker): add native writable mounts - #46
Merged
Conversation
Allow Firecracker start requests to select guest directories that are backed directly by the sandbox's private ext4 writable image. This lets nested storage users such as dockerd avoid placing their overlay on the root OverlayFS while keeping a single storage quota and lifecycle. Forward runtime extra config to handlers, validate mount targets, and teach firecracker-agent to bind per-target native directories into the guest. Document checkpoint semantics and cover configuration, protocol, mount safety, recovery, and end-to-end persistence. Signed-off-by: Tianyu Zhou <albert.zty@antgroup.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
extra_config.nativeWritableMountsfor guest directoriesbacked directly by the sandbox's private ext4 writable image
adding another Firecracker drive or changing the writable-layer quota
already part of
overlay.ext4and mount state is part of the VM snapshotadministrative
sbox startcommand, and document the storage contractExample:
{ "nativeWritableMounts": [ {"target": "/var/lib/docker"} ] }This gives nested storage users a native ext4 path while the guest root
remains EROFS plus OverlayFS. The root upper/work directories and native
writable directories share the same
storage_mbcapacity and lifecycle.Validation
make check-fmtmake vetmake testconsecutive checkpoints, restore, checkpoint-after-restore, quota, network,
and Redis traffic
overlay2, pulledBusyBox, and ran a nested container with no explicit storage-driver setting
selected the equivalent
overlayfssnapshotter on the native ext4 path