What is the problem you're trying to solve

For VM based runtimes that support multiple guests, there really isn't a great way to tell what guest to launch. The problem space isn't as bad when it's same host <-> same guest (linux/linux, windows/windows for example), but it becomes much more pronounced when it's a different host launching something else. The canonical example of this is Windows, specifically LCOW or "Linux Containers on Windows". The way this runtime tells what guest to launch is by filling in the Linux portion of the spec with the desired fields, and then filling in the Windows spec just so it's non-nil, and then nothing else. This works and could also work for a Linux host launching Windows guests in the reverse order, but feels fragile.

The other elephant in the room for LCOW, or any future multi guest runtime, is that k8s doesn't pass any info necessary to generate the right spec to begin with; this is one of the blockers for why LCOW isn't supported in CRI today. Work was started here to accommodate being able to even generate specs for a different platform, but it's missing the piece of the puzzle of how to:

1. Generate the right initial spec for the sandbox.
2. Pass some info to the runtime to tell what guest to setup/what platform this is.

Describe the solution you'd like

A per runtime field that can be set denoting what platform workloads will eventually run in. Something akin to:

// Runtime struct to contain the type(ID), engine, and root variables for a default runtime
// and a runtime for untrusted workload.
type Runtime struct {
	// Type is the runtime type to use in containerd e.g. io.containerd.runtime.v1.linux
	Type string `toml:"runtime_type" json:"runtimeType"`
	// Path is an optional field that can be used to overwrite path to a shim runtime binary.
	// When specified, containerd will ignore runtime name field when resolving shim location.
	// Path must be abs.
	Path string `toml:"runtime_path" json:"runtimePath"`
        
        //
        // Removed for brevity
        //

	// Platform specifies the platform for the workload. This is useful for VM based
	// runtimes to be able to make decisions during bring up based on what platform (operating system mainly)
	// the container will eventually be run in as this may differ from the host. This will set the default
	// runtime spec to the supplied platforms (unless BaseRuntimeSpec is supplied which will take precedence),
	// and set some metadata annotations that the runtime can use to make adjustments to the OCI spec however
	// it sees fit.
	Platform string `toml:"runtime_platform" json:"runtimePlatform"`
}

Then we can add an optional Platform field to the CreateSandboxRequest that we can plumb through the runtime field into.

message CreateSandboxRequest {
	string sandbox_id = 1;
	string bundle_path = 2;
	repeated containerd.types.Mount rootfs = 3;
	google.protobuf.Any options = 4;
        containerd.types.Platform platform = 5;
}

Additional context

No response