CUDA checkpoint fails inside gVisor sandbox (nvproxy) with CUDA_ERROR_OPERATING_SYSTEM / initialization error

[0xAWM]

Description

Summary

CUDA checkpoint/restore fails for GPU processes running inside gVisor (nvproxy).
Host-level CUDA checkpoint works fine on the same GPU/driver.

Environment

• OS: Ubuntu 24.04 (GCP)
• Kernel: 6.14.0-1021-gcp
• GPU: NVIDIA L4
• Driver: 580.105.08
• gVisor/runsc: release-20260126.0
• Runtime: runsc (gVisor)
• CUDA toolkit: 12.0 (nvcc 12.0.140)
• CUDA checkpoint tool: NVIDIA cuda-checkpoint (version 580.105.08) (runsc nvproxy list-supported-drivers)

Expected

CUDA checkpoint tool can initialize and checkpoint the GPU process running in gVisor.

Actual

• In-container wrapper:

[cuda-checkpoint-wrapper] ERROR: cuCheckpointProcessLock for PID failed: CUDA_ERROR_OPERATING_SYSTEM
[cuda-checkpoint-wrapper] ERROR: GPU checkpoint save failed

• Host cuda-checkpoint targeting runsc-sandbox PID:

Error getting process state for process ID : "initialization error"

Minimal logs

Container GPU is healthy:

$ nvidia-smi -L
GPU 0: NVIDIA L4 (UUID: GPU-...redacted...)

$ python3 - <<'PY'
import torch
print("cuda_available", torch.cuda.is_available())
print("device", torch.cuda.get_device_name(0))
x = torch.randn(1024, 1024, device="cuda")
y = x @ x
torch.cuda.synchronize()
print("ok", y[0,0].item())
PY
cuda_available True
device NVIDIA L4
ok

Hypervisor log around snapshot:

[cuda-checkpoint-wrapper] Starting GPU save (checkpoint)
[cuda-checkpoint-wrapper] Found 1 GPU process(es)
[cuda-checkpoint-wrapper] Checkpointing 1 process(es)...
[cuda-checkpoint-wrapper] ERROR: cuCheckpointProcessLock for PID 1091866 failed: CUDA_ERROR_OPERATING_SYSTEM (OS call failed or operation not supported on this OS)
[cuda-checkpoint-wrapper] ERROR: Failed to process 1/1 CUDA process(es)
[cuda-checkpoint-wrapper] ERROR: GPU checkpoint save failed

Notes

• Host CUDA checkpoint works on native CUDA processes with the same driver/tool.
• Failure happens only for GPU processes inside gVisor/nvproxy (runsc-sandbox).

Question

Is CUDA checkpoint/restore supported for GPU processes running under nvproxy?
If not, is there any planned support or documented limitation?

Steps to reproduce

Repro steps

1. Run a CUDA process inside gVisor (e.g. PyTorch CUDA).
2. In the container, confirm GPU works:

nvidia-smi -L
python3 - <<'PY'
import torch
print(torch.cuda.is_available())
x = torch.randn(1024,1024,device="cuda")
y = x @ x
torch.cuda.synchronize()
print(y[0,0].item())
PY

3. Try GPU checkpoint inside the container:

GVISOR_SAVE_RESTORE_AUTO_EXEC_MODE=save /etc/.test/cuda-snapshot

4. Or from host using NVIDIA cuda-checkpoint on the runsc-sandbox PID:

sudo /tmp/nv_cuda_checkpoint --get-state --pid

runsc version

runsc version release-20260126.0
spec: 1.1.0-rc.1

docker version (if using docker)

uname

Linux

kubectl (if using Kubernetes)

repo state (if built from source)

No response

runsc debug logs (if available)

{"msg":"checkpoint failed: checkpointing container \"task-uuid0\": failed to exec save/restore binary: /etc/.test/cuda-snapshot exited with
  non-zero status 256","level":"error"}

[EtiennePerot]

Is CUDA checkpoint/restore supported for GPU processes running under nvproxy?

It should be supported. Thanks for the repro. I suggest also providing runsc logs, they should show if it encountered any nvproxy compatibility problem. If not, there's also --strace that may be worth enabling; perhaps cuda-checkpoint is starting to probe for which OS it's running in, in a way that doesn't work in gVisor.

[0xAWM]

@EtiennePerot Thanks for the suggestion — that was very helpful!

I’ve added the requested logs below after reproducing the issue again.
Hopefully they make the behavior clearer.

runsc global config:

debug = "true"
strace = "true"
strace_syscalls = "futex,clone,clone3,execve,open,ioctl,mmap,munmap,prctl"

Checkpoint failure:

ERROR:
  Code: Internal
  Message: Failed to create checkpoint: Failed to snapshot container task checkpoint failed: checkpointing container "task": encoding error: Can't save pma with non-MemoryFile of type *nvproxy.frontendFDMemmapFile:
goroutine 606 [running]:
gvisor.dev/gvisor/pkg/state.safely.func1()
	pkg/state/state.go:309 +0x16e
panic({0x11d0d60?, 0xc000ac5580?})
	GOROOT/src/runtime/panic.go:783 +0x132
gvisor.dev/gvisor/pkg/sentry/mm.(*pma).saveFile(0x4198df?)
	pkg/sentry/mm/save_restore.go:151 +0xf9
gvisor.dev/gvisor/pkg/sentry/mm.(*pma).StateSave(0xc0019eefe8, {{0xc001706008?, 0xc000e50bb8?}})
	bazel-out/k8-opt/bin/pkg/sentry/mm/mm_state_autogen.go:377 +0x30
gvisor.dev/gvisor/pkg/state.(*encodeState).encodeStruct(0xc001706008, {0x13aeb20, 0xc0019eefe8, 0x199}, 0xc000e4f2e0)
	pkg/state/encode.go:536 +0x58e
gvisor.dev/gvisor/pkg/state.(*encodeState).encodeObject(0xc001706008, {0x13aeb20?, 0xc0019eefe8?, 0xc0012285f8?}, 0x0?, 0xc000e4f2e0)
	pkg/state/encode.go:733 +0x5e5
gvisor.dev/gvisor/pkg/state.(*objectEncoder).save(0x133eb00?, 0xc0019eefe8?, {0x13aeb20?, 0xc0019eefe8?, 0x1309b00?})
	pkg/state/encode.go:477 +0x8c
gvisor.dev/gvisor/pkg/state.Sink.Save({{0xc001706008, 0xc000e50b88}}, 0x2, {0x133eb00?, 0xc0019eefe8?})
	pkg/state/state.go:160 +0x9d
gvisor.dev/gvisor/pkg/sentry/mm.(*pmaFlatSegment).StateSave(0xc0019eefd8, {{0xc001706008?, 0xc000e50b88?}})
	bazel-out/k8-opt/bin/pkg/sentry/mm/mm_state_autogen.go:494 +0x8d
gvisor.dev/gvisor/pkg/state.(*encodeState).encodeStruct(0xc001706008, {0x1309bc0, 0xc0019eefd8, 0x199}, 0xc000bcdd18)
	pkg/state/encode.go:536 +0x58e
gvisor.dev/gvisor/pkg/state.(*encodeState).encodeObject(0xc001706008, {0x1309bc0?, 0xc0019eefd8?, 0x0?}, 0xc001228810?, 0xc000bcdd18)
	pkg/state/encode.go:733 +0x5e5
gvisor.dev/gvisor/pkg/state.(*encodeState).encodeArray(0xc001706008, {0xc0007fe960?, 0xc0019da000?, 0x199?}, 0xc0016abb80)
	pkg/state/encode.go:550 +0x110
gvisor.dev/gvisor/pkg/state.(*encodeState).encodeObject(0xc001706008, {0xc0007fe960?, 0xc0019da000?, 0xc000680008?}, 0x0?, 0xc0016abb80)
	pkg/state/encode.go:714 +0x3bd
gvisor.dev/gvisor/pkg/state.(*encodeState).Save.func2()
	pkg/state/encode.go:770 +0x8b
gvisor.dev/gvisor/pkg/state.safely(0xc001706008?)
	pkg/state/state.go:322 +0x51
gvisor.dev/gvisor/pkg/state.(*encodeState).Save(0xc001706008, {0x1452360?, 0xc0003f4008?, 0xc001706008?})
	pkg/state/encode.go:763 +0x1f5
gvisor.dev/gvisor/pkg/state.Save.func1()
	pkg/state/state.go:104 +0x8e
gvisor.dev/gvisor/pkg/state.safely(0xa9d657?)
	pkg/state/state.go:322 +0x51
gvisor.dev/gvisor/pkg/state.Save({0x764285058400, 0xc0001bbd80}, {0x764283b74430, 0xc0008db800}, {0x1452ae0, 0xc0003f4008})
	pkg/state/state.go:103 +0x1c5
gvisor.dev/gvisor/pkg/sentry/kernel.(*Kernel).SaveTo(0xc0003f4008, {0x16a8598, 0xc0001bbd80}, {0x1687798, 0xc0008db800}, {0x0, 0x0}, {0x0, 0x0}, 0x0, ...)
	pkg/sentry/kernel/kernel.go:721 +0xba5
gvisor.dev/gvisor/pkg/sentry/state.(*SaveOpts).Save(0xc0007b83c0, {0x16a8598, 0xc0001bbd80}, 0xc0003f4008, 0xc000216080)
	pkg/sentry/state/state.go:109 +0x325
gvisor.dev/gvisor/pkg/sentry/control.(*State).SaveWithOpts(0xc001229518, 0xc0007b83c0, 0x146b575?)
	pkg/sentry/control/state.go:183 +0xb2
gvisor.dev/gvisor/runsc/boot.(*Loader).saveWithOpts(0xc000176b08, 0xc0007b83c0, 0xc0000cd348)
	runsc/boot/restore.go:460 +0x265
gvisor.dev/gvisor/runsc/boot.(*Loader).save(0xc000176b08, 0xc0000cd300)
	runsc/boot/restore.go:422 +0x89
gvisor.dev/gvisor/runsc/boot.(*containerManager).Checkpoint(0xc0001ba280, 0xc0000cd300, 0x0?)
	runsc/boot/controller.go:495 +0x52
reflect.Value.call({0xc0003842a0?, 0xc0004d8060?, 0xc001189c18?}, {0x145f1b9, 0x4}, {0xc001189ea8, 0x3, 0xc001189c48?})
	GOROOT/src/reflect/value.go:581 +0xcc6
reflect.Value.Call({0xc0003842a0?, 0xc0004d8060?, 0x120?}, {0xc001189ea8?, 0xc0000cd300?, 0x16?})
	GOROOT/src/reflect/value.go:365 +0xb9
gvisor.dev/gvisor/pkg/urpc.(*Server).handleOne(0xc000222870, 0xc00001c780)
	pkg/urpc/urpc.go:343 +0x6b6
gvisor.dev/gvisor/pkg/urpc.(*Server).handleRegistered(...)
	pkg/urpc/urpc.go:454
gvisor.dev/gvisor/pkg/urpc.(*Server).StartHandling.func1()
	pkg/urpc/urpc.go:474 +0x67
created by gvisor.dev/gvisor/pkg/urpc.(*Server).StartHandling in goroutine 34
	pkg/urpc/urpc.go:472 +0x6b

for object [1499]mm.pmaFlatSegment{... file:(*nvproxy.frontendFDMemmapFile)(0xc0003ef850), ...}

Happy to provide more details or test any hypotheses if needed.
Thanks again for your support!

[EtiennePerot]

Thanks for re-running. This Can't save pma with non-MemoryFile of type *nvproxy.frontendFDMemmapFile error is fairly typical after trying to checkpoint a sandbox with a CUDA process but where cuda-checkpoint didn't succeed at actually checkpointing that CUDA process; it's just complaining that there are still CUDA-related stuff in the kernel that cuda-checkpoint is supposed to get rid of.

Please set the debug-log flag to something like /tmp/runsc-logs/ (the trailing slash is important); you'll get logs under that directory, the relevant one is the one that ends in .boot.txt. Please provide its contents, I suspect it'll have relevant nvproxy warnings there.

[EtiennePerot]

In order to repro, I would also need to know the specific CUDA process you are running, as well as the contents of /etc/.test/cuda-snapshot (probably a script that runs cuda-checkpoint?).

The CUDA workload is necessary information, because some CUDA processes use more or less of the CUDA API surface, and it's possible yours is using some that we haven't encountered (for example, some of them also use NCCL, which isn't supported by cuda-checkpoint: NVIDIA/cuda-checkpoint#5). If running vLLM, there's a lot of knobs that go into how it uses the CUDA API that depend on GPU type, number of GPUs, host capabilities, and vLLM flags, all of which are relevant.

I would also recommend double-checking that checkpointing and restoring the workload actually works when running within a non-gVisor Docker container (not directly on the host). We've observed lots of small incompatibilities in the cuda-checkpoint tool that only trigger in certain scenarios, such as when only exposing a subset of the host's GPU to a container (see upstream bug NVIDIA/cuda-checkpoint#27)