Skip to content

Comments

snapshot: fix proxy mode mounting for snapshots without nydus-proxy mode label#708

Draft
fidencio wants to merge 1 commit intocontainerd:mainfrom
fidencio:topic/snapshot-fix-proxy-mode-mounting-for-snapshots-without-nydus-proxy-mode-label
Draft

snapshot: fix proxy mode mounting for snapshots without nydus-proxy mode label#708
fidencio wants to merge 1 commit intocontainerd:mainfrom
fidencio:topic/snapshot-fix-proxy-mode-mounting-for-snapshots-without-nydus-proxy-mode-label

Conversation

@fidencio
Copy link
Contributor

@fidencio fidencio commented Feb 1, 2026

Overview

When containerd unpacks an image for a remote snapshotter like nydus in proxy mode, it passes the CRIImageRef label via snapshots.WithLabels during the Prepare/Unpack flow. This label contains the image reference needed by nydus to construct the kata virtual volume metadata.

The mountProxy() function was being called without passing the available labels, creating a rafs.Rafs{} with an empty Annotations map. This caused nydus to fall back to using "dummy-image-reference" as the source, breaking guest-side image pulling. The fix passes the labels through to mountProxy() so CRIImageRef is available when constructing the kata virtual volume.

Additionally, snapshots may have CRIImageRef but lack the nydus-proxy-mode label. This happens when an image was unpacked before containerd properly set all labels, or when labels were updated via containerd's fixSnapshotLabels after the initial unpack. In these cases the code would incorrectly call mountNative() instead of mountProxy(), causing mount failures because proxy mode directories don't contain actual content (content is pulled inside the guest). The fix adds a fallback check before mountNative: if we're in proxy driver mode and the snapshot or its parent chain has CRIImageRef, use mountProxy instead.

Change Type

Please select the type of change your pull request relates to:

  • Bug Fix
  • Feature Addition
  • Documentation Update
  • Code Refactoring
  • Performance Improvement
  • Other (please describe)

@fidencio
Copy link
Contributor Author

fidencio commented Feb 1, 2026

This has been tested together with containerd/containerd#12835

@codecov
Copy link

codecov bot commented Feb 1, 2026

Codecov Report

❌ Patch coverage is 0% with 40 lines in your changes missing coverage. Please review.
✅ Project coverage is 21.20%. Comparing base (9fff1cc) to head (c491a4e).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
snapshot/snapshot.go 0.00% 39 Missing ⚠️
snapshot/process.go 0.00% 1 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main     #708      +/-   ##
==========================================
- Coverage   21.26%   21.20%   -0.07%     
==========================================
  Files         126      126              
  Lines       11445    11481      +36     
==========================================
  Hits         2434     2434              
- Misses       8682     8718      +36     
  Partials      329      329              
Files with missing lines Coverage Δ
snapshot/process.go 0.00% <0.00%> (ø)
snapshot/snapshot.go 5.67% <0.00%> (-0.29%) ⬇️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@fidencio
Copy link
Contributor Author

fidencio commented Feb 1, 2026

cc @imeoer

if mountLabels == nil {
mountLabels = make(map[string]string)
}
if _, ok := mountLabels[label.CRIImageRef]; !ok && info.Parent != "" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code for walking the parent chain to find CRIImageRef is duplicated in three places (lines ~456, ~500, and ~528).
Could we refactor this into a helper function?
Others LGTM. Thanks for the PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BraveY, updated, thanks!

@fidencio fidencio force-pushed the topic/snapshot-fix-proxy-mode-mounting-for-snapshots-without-nydus-proxy-mode-label branch from b033fb3 to d96423f Compare February 2, 2026 08:50
// Handle the case where the snapshotter is in proxy mode and the snapshot has
// CRIImageRef label but not nydus-proxy-mode label. This can happen when:
// 1. The image was unpacked before the containerd fix that adds proper labels
// 2. The labels were updated after the initial unpack via containerd's fixSnapshotLabels
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @fidencio , thanks for the PR, can we explain what's fixSnapshotLabels here? others LGTM!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I will do the addition later Today. Thanks @imeoer!

Copy link
Contributor Author

@fidencio fidencio Feb 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed, and moved the PR to "Draft" till the work on containerd side gets merged.

…ode label

When containerd unpacks an image for a remote snapshotter like nydus
in proxy mode, it passes the CRIImageRef label via snapshots.WithLabels
during the Prepare/Unpack flow. This label contains the image reference
needed by nydus to construct the kata virtual volume metadata.

The mountProxy() function was being called without passing the available
labels, creating a rafs.Rafs{} with an empty Annotations map. This caused
nydus to fall back to using "dummy-image-reference" as the source,
breaking guest-side image pulling. The fix passes the labels through to
mountProxy() so CRIImageRef is available when constructing the kata
virtual volume.

Additionally, snapshots may have CRIImageRef but lack the
nydus-proxy-mode label. This happens when an image was unpacked before
containerd properly set all labels, or when labels were updated as
containerd detected that existing snapshots had incorrect labels (for
instance, a digest instead of a pullable image reference) and updated
then to contain the correct CRIImageRef valye beeded for guest-side
pulling after the initial unpack.

In the cases mentioned above the code would incorrectly call
mountNative() instead of mountProxy(), causing mount failures because
proxy mode directories don't contain actual content (content is pulled
inside the guest). The fix adds a fallback check before mountNative: if
we're in proxy driver mode and the snapshot or its parent chain has
CRIImageRef, use mountProxy instead.

Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
@fidencio fidencio force-pushed the topic/snapshot-fix-proxy-mode-mounting-for-snapshots-without-nydus-proxy-mode-label branch from d96423f to c491a4e Compare February 2, 2026 15:11
@fidencio fidencio marked this pull request as draft February 2, 2026 15:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants