runtime-rs CLH VM factory rejects required shared_fs=none configuration

Environment

• Kata Containers: 4.1.0
• Runtime: runtime-rs
• Hypervisor: Cloud Hypervisor
• Architecture: x86_64
• Host: GKE nested KVM
• Kubernetes: 1.35
• containerd: 2.1

Motivation

We are evaluating Cloud Hypervisor VM templates for a sandbox platform. The goal is to restore a pre-booted Kata VM to reduce cold-start and pool-replenishment latency.

The shipped CLH runtime-rs configuration says:

CLH templating requires no shared filesystem and a block-capable snapshotter.

Configuration

[hypervisor.clh]
image = ""
initrd = "/opt/kata/share/kata-containers/kata-containers-initrd.img"
shared_fs = "none"
default_vcpus = 1
default_maxvcpus = 1
default_memory = 2048
default_maxmemory = 2048

[hypervisor.clh.factory]
enable_template = true
template_path = "/run/vc/vm/template-clh"

Reproduction

Run:

kata-ctl factory init

Expected behavior

The factory should start a clean CLH VM without a shared filesystem and save the template memory/device state.

Actual behavior

Factory initialization fails before the VM starts:

failed to initialize factory
  new factory
    initialize VM template factory
      create template files
        new template vm
          start template
            set up device before start vm
              new share fs
                unsupported shared fs "none"

Apparent root cause

For a non-TDX CLH VM, CloudHypervisorInner::capabilities() unconditionally includes CapabilityBits::FsSharingSupport, regardless of config.shared_fs:

CapabilityBits::BlockDeviceSupport
    | CapabilityBits::BlockDeviceHotplugSupport
    | CapabilityBits::BlockDeviceDiscardSupport
    | CapabilityBits::FsSharingSupport
    | CapabilityBits::HybridVsockSupport
    | CapabilityBits::NetworkDeviceHotplugSupport

ResourceManagerInner::prepare_before_start_vm() then always calls share_fs::new() when processing ResourceConfig::ShareFs. The share-fs factory accepts inline-virtio-fs, virtio-fs, and virtio-fs-nydus, but rejects none.

This conflicts with the CLH template requirement to use no shared filesystem. The same unconditional CLH capability and resource-manager behavior appears in the 4.2.0 source.

Additional observations

• The existing image-backed CLH configuration with shared_fs = "virtio-fs" starts normal Kata sandboxes successfully.
• We restored that working configuration after the factory test.
• No template memory/state files were successfully created.
• The failure occurs before evaluating the block-capable snapshotter path, so template performance could not be measured.
• CLH runtime-rs template support was introduced by #13387.
• The separate factory configuration-loading issue is tracked by #13501 and #13594.

Questions

1. Should CLH omit FsSharingSupport when shared_fs is none?
2. Should the resource manager skip ResourceConfig::ShareFs when the configured shared filesystem is none?
3. Is there another supported value or deployment path for CLH VM templates with runtime-rs?
4. Is there CI coverage for kata-ctl factory init using CLH, initrd, shared_fs=none, and a block-capable snapshotter?