Use a RO snapshot of container to retrieve unikernel binary

[cmainas]

In the case where we use devmapper as a snapshotter in urunc, we have the benefit of directly using the container rootfs as the block image to pass it to the unikernel. However, to do that, we need to copy the unikernel image, the initrd and urunc.json file, unmount the container rootfs and then give it to the unikernel.

We can remove the file copies by requesting a view (read-only) snapshot of the container rootfs. Therefore, instead of copying the files, we could simply mount the new snapshot and directly read the unikernel binary and rest files from there. In theory, this approach will not have any storage overhead, since the snapshot will simply redirect the read requests to the underneath snapshot layer (actual container rootfs).

Ideally, we could mark and select the layers that contain the unikernel image to create the new snapshot. However, this might require a lot of changes, outside of urunc.

In order to create the new snapshot, we need to communicate with containerd in order to request to create the snapshot for us. We need to investigate how we can do that.

[Mysterio-17]

@cmainas, I’m interested in working on this issue and would like to get assigned

[sidneychang]

Hi, I’m very interested in this project and in snapshotter-related work in general.

I have some background with the container runtime stack and previously contributed to Kata Containers and Nydus. Since Nydus is implemented as a snapshotter, I became particularly interested in snapshotter design and have also studied the overlayfs snapshotter implementation.

I’d be very happy to contribute or help with this project if there are suitable tasks or discussions to join. Thanks!

[cmainas]

Hello @Mysterio-17 and @sidneychang ,

thank you for expressing interest to urunc and specifically this issue.

This issue will be part of the LFX mentorship program for the first term of 2026. Therefore, we will not assign nor accept any PRs related to this issue until the mentorship program starts. We kindly invite everyone, interested in urunc and this issue, to apply for a mentorship following the CNCF guidelines. If you have any question specific to this issue, feel free to ask it here.

Apply though LFX mentorship portal

A few more information about this idea:

Description

When urunc is used together with a block-based snapshotter, it can take advantage of block-device backed container root filesystem and pass it directly to the sandbox as a disk image. This approach avoids filesystem conversion and enables efficient access to the container root filesystem.

However, in order to spawn the sandbox, urunc requires access to the guest kernel and the initrd (if present). Since these files are part of the container rootfs, urunc must first extract and store them elsewhere before attaching the block-based root filesystem to the sandbox. As a result, this process introduces unnecessary file copies and additional I/O overhead.

A more efficient approach is to leverage read-only (view) snapshots. Instead of copying files, urunc could request a read-only snapshot of the container root filesystem and mount it separately. The kernel binary and other required artifacts could then be read directly from this snapshot without modifying or duplicating data. Since view snapshots simply redirect read requests to the underlying snapshot layers, this approach is expected to introduce little to no additional storage overhead while simplifying the runtime flow.

Expected Outcome:

• A document explaining block-based snapshots in containerd, along with the respective APIs to snapshot creation and management.
• An implementation in urunc that requests and mounts a read-only snapshot of the container root filesystem.
• Evaluation of performance, storage overhead, and limitations of the snapshot-based approach.

Recommended Skills:

• Go
• Familiarity with containerd
• Familiarity with Linux filesystems and block devices

Mentor(s):

• Charalampos Mainas (@cmainas, cmainas@nubificus.co.uk)
• Anastassios Nanos (@ananos, ananos@nubificus.co.uk)

Additional material for the the selection process:

This issue touches various components of the container management systems. Therefore, we kindly ask all interested mentees to perform the following tasks:

• Set up an environment with uruncinstalled
• Set up devmapper and/or blockfile as a snapshotter
• Run a container over urunc using devmapper and/or blockfile as a snapshotter

In addition, we kindly ask all interested mentees to submit the following material along with their application:

• A brief summary of the above exercise, pointing out the steps they performed, what they found difficult, not well documented etc.
• A proposal with a plan on how to approach a solution for the above issue. This does not need to be exhaustive; we are mostly interested in understanding the thought process and the approach of the mentee.

Note

Feel free to use LLMs to refine the proposal, but do not use LLMs to write the entire proposal. We are interested about the mentee's ideas, not for a generated project plan.