guest: unify pod model for V1, virtual pod, and V2 shim support#2662
Open
shreyanshjain7174 wants to merge 2 commits intomicrosoft:mainfrom
Open
guest: unify pod model for V1, virtual pod, and V2 shim support#2662shreyanshjain7174 wants to merge 2 commits intomicrosoft:mainfrom
shreyanshjain7174 wants to merge 2 commits intomicrosoft:mainfrom
Conversation
Replace heuristic sandbox path derivation (hard-coded /run/gcs/c prefix + ID) with host-provided OCIBundlePath as the canonical sandbox root directory. This change prepares the guest-side GCS for Shim v2 and multi-pod UVM support, where the host may use a different path layout than the legacy /run/gcs/c/<id>. Key changes: - Add sandboxRoots mapping on Host to store resolved sandbox root per sandbox ID - Sandbox containers: register OCIBundlePath as sandbox root - Virtual pods: derive sandbox root from OCIBundlePath parent + /virtual-pods/<id> - Workload containers: resolve sandbox root from Host mapping (fallback to legacy) - Standalone containers: use OCIBundlePath directly as root - Container.Delete: use stored sandboxRoot for cleanup paths - Remove duplicate setup functions (setupVirtualPod* merged into unified setup*) The refactor produces identical paths when the old shim sends OCIBundlePath in the legacy format, ensuring zero behavior change for existing deployments. Security: virtualPodID is validated against path traversal before use. Signed-off-by: Shreyansh Sancheti <shsancheti@microsoft.com>
shreyanshjain7174
force-pushed
the
guest-pod-unification
branch
from
2c315a9 to
38631fd
Compare
Signed-off-by: Shreyansh Sancheti <shsancheti@microsoft.com>
shreyanshjain7174
force-pushed
the
guest-pod-unification
branch
from
38631fd to
2c5aea1
Compare
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
1 participant
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.
Depends on #2653 — must merge first.
The GCS guest runtime (
internal/guest/runtime/hcsv2/uvm.go) tracks virtual pods separately from V1 sandbox containers — dedicatedvirtualPodsmap,VirtualPodtype, reverse lookup table, parent cgroup manager, and seven pod-specific methods. V1 sandboxes have no pod-level tracking. The V2 shim would need a third path.This collapses all three into one: a private
uvmPodtype and a singlepodsmap onHost.createPodInUVMallocates a cgroup under/pods/{sandboxID}for any pod type.addContainerToPodtracks which containers belong where. The virtual-pod-specific API surface is gone — callers go through the same path regardless of pod flavor.Cgroup management uses the unified
cgroup.Managerinterface so it works on both cgroupv1 and v2 hosts.