LinuxContainer/LinuxPod: Single file support #487
Merged
+598
−6
Conversation
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
This adds support for single file (virtiofs based) mounts to the two main container types. This is transparent, and doesn't need to be setup by a user, so there is no visible API change. Virtiofs does not support single file mounts today, and it would be less than ideal from a security standpoint to just expose the parent directory of the file to the vm and then bind mount in the file, so we chose the following: 1. Create a temp directory the container types will manage. 2. Hardlink in the file we want. 3. Share that tempdir into the vm. 4. Finally bind mount in the file into the container. The main goal I wanted for this is to leave the logic out of the `VirtualMachineInstance`. I really want this to just be a little dance the container types do, and leave the vm out of it. Because of that, most of the logic is shoved in a new `FileMountContext` type that does the dirty tricks of rewriting what the user asked for to be a bind mount from a temporary holding spot we'll use in the guest for these temp directories. One of the downsides to this is today the tempdirs are solely on the main volume, so cross volume will need to copy the file to the tempdir, so writes won't get written back. Co-authored-by: Dean Coulstock <d_coulstock@apple.com> Co-authored-by: Jaewon Hur <hurjaewon@snu.ac.kr>
dcantah
force-pushed
the
support-single-file-mounts
branch
from
fe68317 to
62a0614
Compare
jglogan
reviewed
Jan 22, 2026
jglogan
reviewed
Jan 22, 2026
jglogan
approved these changes
Jan 23, 2026
| try FileManager.default.linkItem(at: resolvedSource, to: destURL) | ||
| } catch { | ||
| // Hardlink failed. Fall back to copy | ||
| try FileManager.default.copyItem(at: resolvedSource, to: destURL) |
Contributor
There was a problem hiding this comment.
We might want our documentation on Mount to state that the caller is responsible for determining whether cross-filesystem mounts are present.
For "caller == container" we'd want to warn the user in the case that their single file mount won't actually propagate guest writes through to the host file.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Fixes #79
This adds support for single file (virtiofs based) mounts to the two main container types. This is transparent, and doesn't need to be setup by a user, so there is no visible API change. Virtiofs does not support single file mounts today, and it would be less than ideal from a security standpoint to just expose the parent directory of the file to the vm and then bind mount in the file, so we chose the following:
The main goal I wanted for this is to leave the logic out of the
VirtualMachineInstance. I really want this to just be a little dance the container types do, and leave the vm out of it. Because of that, most of the logic is shoved in a newFileMountContexttype that does the dirty tricks of rewriting what the user asked for to be a bind mount from a temporary holding spot we'll use in the guest for these temp directories.One of the downsides to this is today the tempdirs are solely on the main volume, so cross volume will need to copy the file to the tempdir, so writes won't get written back.