documentation on creating copy-on-write filesystems

[pfandzelter]

Signed-off-by: Tobias Pfandzelter pfandzelter@campus.tu-berlin.de

Reason for This PR

Firecracker can be used with copy-on-write filesystems, which allows multiple microVMs to share a common read-only rootfs with individual write-layers, either in a temporary tmpfs or persisted in an ext4 formatted file.
This can save significant storage space on the host as no copies of the same rootfs have to be created.
So far we were not able to find any documentation on how to achieve this, similarly to #987.

This technique is already used in firecracker-containerd.
This PR proposes new documentation on how to achieve this with out-of-the-box Firecracker, e.g., on the command-line or in firecracker-go-sdk.
In fact, our documentation is mainly adapted from the firecracker-containerd image-builder documentation.

Note that our solution is not perfect for every use case, especially as it requires some guest cooperation to mount the filesystem correctly. But it works out of the box without changes to Firecracker.

We're also happy about any feedback! Currently we include a slightly modified copy of the init script from firecracker-containerd, maybe there is a better way to include this here?

Description of Changes

Adds documentation on how to set up microVMs with layered, copy-on-write filesystems to share rootfs across microVMs.

• This functionality can be added in rust-vmm.

License Acceptance

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license.

PR Checklist

[Reviewer TODO: Verify that these criteria are met. Request changes if not]

• All commits in this PR are signed (git commit -s).
• The issue which led to this PR has a clear conclusion.
• This PR follows the solution outlined in the related issue.
• The description of changes is clear and encompassing.
• Any required documentation changes (code and docs) are included in this PR.
• Any newly added unsafe code is properly documented.
• Any API changes are reflected in firecracker/swagger.yaml.
• Any user-facing changes are mentioned in CHANGELOG.md.
• All added/changed functionality is tested.

[pfandzelter]

Tests reported some formatting errors with the git commit message and markdown style, these should be fixed now

[xmarcalx]

Dear @pfandzelter ,

first of all sorry for the late reply and for addressing this PR after so long.
We have recently reviewed with the team the PR again and we decided that we will not move forward with merging the change in the official documentation because, as per today, we do not actually officially support and test such mechanism in Firecracker. Such lack of testing may leave space for stale information, vulnerabilities or regressions which we will not be aware of, introducing a risk for all the users which rely on our documentation to be production ready.
At the same time, we realize the value and impact of sharing best practices and/or solution developed with Firecracker to solve specific problems among the community. For this reason we would like to establish a format in the form of Discussions within the "Show and Tell" section section to collect and share documentation, anecdotes or blog posts and collect from the community members.

This PR represent therefore the perfect example to start in this direction and we would like to propose to convert the content of the documentation to be the first discussion in our "Show and Tell" section with the intention to pave the road and show to the community a mechanism to be followed by many other members who have similar intentions.

Please let us know your thoughts and Thanks again for your contribution!

[pfandzelter]

Hi @xmarcalx, sounds good to me! We did the work and thought the community might benefit from this information being somewhere, so if you want to include it in "Show and Tell" that would be great for everyone. Feel free to post it there and close the PR

[xmarcalx]

Hi @pfandzelter ,

Thank you very much for your message and your understanding. We truly believe that such info would benefit many other in the community.
I included your documentation in this discussion #3061 and closing this PR.

Thanks again for your contribution and we can not wait for the next one!