Build regular block volumes with BlockConfigModern and submit them
through DeviceConfig::BlockCfgModern. Preserve the existing block
device attributes while also recording the host path required by the
modern block device model.
Update block volume helper call sites with the default option slice
so this change remains buildable with the modern helper signature.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Switch the Cloud Hypervisor device handling path from the legacy
Block device variant to BlockModern. Keep the block device behind
its shared mutex while snapshotting the configuration for the
hotplug request, and persist the PCI path assigned by Cloud
Hypervisor back into the shared device state.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Introduce build_bind_mount_options() to construct OCI mount options for
container-side bind mount, preferring volume_options over OCI options
and ensuring a bind/rbind flag is present.
And addfilter_block_storage_options() to strip bind/rbind flags from
Storage.options, preventing ENOTDIR when the agent mounts a block
device to a filesystem inside the guest.
And then Extend handle_block_volume() with a volume_options parameter
and replace hardcoded ro/empty options with the new filter+ro logic,
narrowing the function to a BlockModern-only path by removing the
DeviceType::Block branch.
Fix generate_shared_path to always create under rw/ since ro/
is a read-only bind mount of rw/ and direct creation fails with ReadOnly
FS. Switch the OCI Mount type from fs_type to KATA_MOUNT_BIND_TYPE because
the mount source is a directory (guest_path), not a block device.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Move the block device type definitions shared between BlockDevice and
BlockDeviceModern — VIRTIO_BLOCK_{PCI,MMIO,CCW}/VIRTIO_PMEM constants,
KATA_*_DEV_TYPE aliases, and the BlockDeviceAio / BlockDeviceFormat
enums — from virtio_blk.rs into virtio_blk_modern.rs, so they live
alongside the BlockModern handler that will replace the legacy
BlockDevice.
Add a `format: BlockDeviceFormat` field to BlockConfigModern to match
the legacy BlockConfig. Update mod.rs re-exports accordingly.
No behavior change; pure relocation plus the new field.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Extend add_block_device with num_queues and queue_size parameters
to support multi-queue virtio-blk configuration, and add BlockModern
hotplug/hotunplug handler that extracts config from
Arc<Mutex<BlockDeviceModern>>, passes the new parameters to
add_block_device, and updates pci_path on successful hotplug.
And we will use BlockDeviceModern to handle block device instead of
Legacy BlockDevice.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Add BlockModern handling in DeviceManager so that device index is
correctly released both in get_device_info and in the error path.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Use the hotplug-returned SCSI address as Storage.source when a
container rootfs is backed by a block device.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
The network hotplug (handle_network_device) passed `queue_num`, a
queue pair count, straight as `num_queues`, while cloud-hypervisor's
virtio-net expects a raw virtqueue count.
With the default network_queues=1 this hit "Number of queues (1) to
virtio_net should be higher than 2" on the post-start netdev add,
failing sandbox start.
Convert the pair count to the raw queue count (queue_num.max(1) * 2),
matching the coldplug path which already does network_queues_pairs * 2.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
NetworkConfig.queue_num is a queue pair count, but Dragonball's
virtio/vhost-net backends expect an even raw virtqueue count. Passing
it through without doubling caused InvalidQueueNum(1) on the default
network_queues=1, failing sandbox start.
Convert pair count to raw count (queue_num.max(1) * 2) at both
Dragonball network entry points, mirroring the Cloud Hypervisor
backend.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
As part of the effort to thread network queues from the top-level
configuration all the way down to each endpoint instead of having
low-level helpers re-read the global configuration, propagate the
per-network queue_num into the QEMU cmdline generator and hotplug
path.
add_network_device() and get_network_device() now take an explicit
num_queues argument sourced from network.config.queue_num, replacing
the direct read of network_info.network_queues, so each network
endpoint honors its own configured queue count.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
As there's no field to map the configuration's network_queues item
in the `DanConfig`, this commit introduces a network_queues to do this.
And accordingly, we also make it passed down from sandbox layer to
Dan network configurations.
To make it work well, it make it more robust for queues and queue_size
settings with checking logics. And related UT is added.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Set queue_num (derived from net_pair.queues, one TX + one RX per
queue pair) and queue_size (256) when building the network pair for
veth, macvlan, ipvlan and vlan endpoints so the virtio-net device is
created with the configured multi-queue layout.
Meanwhile, update endpoint tests accordingly.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Number of virtio queue pairs (each pair = 1 RX + 1 TX).
Derived from `network_queues` in the hypervisor TOML config.
Signed-off-by: Alex Lyn <alex.lyn@antgroup.com>
Move runtime-rs onto containerd-shim/containerd-shim-protos 0.11.0,
which drops the legacy cgroups-rs 0.3.x dependency. Adapt to ttrpc
0.9 API changes for async connect, server listener setup, and event
forwarding.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Composer <cursor@cursor.com>
Unify agent, rustjail, and runtime-rs on cgroups-rs 0.5.1 from
crates.io instead of the v0.3.5 git fork. Add a rustjail shim for
the 0.5.x API layout where the legacy cgroupfs types moved under
cgroups::fs.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Composer <cursor@cursor.com>
qemu-nvidia-gpu boots the driver-agnostic NVIDIA base image and then
cold-plugs the GPU extension on top. Nothing, however, just boots that
base image on NVIDIA hosts that have no GPU (or where the GPU isn't handed
to the guest), even though the base image is perfectly usable on its own.
Add qemu-nvidia-cpu (Go) and qemu-nvidia-cpu-runtime-rs (Rust), cloned
from the qemu-nvidia-gpu configs with every GPU-passthrough bit dropped:
no guest_extension_images, cold_plug_vfio = "no-port", pcie_root_port = 0,
no VFIO pod-resource wiring and no GPU NUMA validation. Resource defaults
and timeouts are pulled back in line with qemu[-runtime-rs] (1 vCPU,
DEFMEMSZ, small overheads) rather than the GPU-tuned values, and firmware
is left to the arch default so x86_64 boots without OVMF.
Both classes boot the measured nvidia base image verity-backed. The Rust
runtime already maps KERNELVERITYPARAMS_NV to the base hash; the Go runtime
maps it to the monolith, so a dedicated KERNELVERITYPARAMS_NV_BASE var is
added for qemu-nvidia-cpu.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Use an explicit memory-backend-ram object for normal,
non-file-backed QEMU memory and bind it through the machine
memory-backend option.
This aligns the runtime-rs QEMU command line more closely with the
runtime-go QEMU path when filesystem sharing is disabled. Further,
when enable_mem_prealloc is enabled, runtime-rs now emits
prealloc=on for that backend, matching the runtime-go behavior.
This supports #13363, where the non-confidential NVIDIA runtime-rs
handler disables filesystem sharing and uses the EROFS snapshotter as
its Kubernetes image-layer transport. This is expected to reduce the
likelihood of the QMP startup delays seen in #13084 for NVIDIA GPU
passthrough with filesystem sharing disabled. A separate issue on the
behavior of the QMP timeout logic is additionally tracked in #13343.
In addition to these changes, #12187 tracks a machine-centric QEMU
refactor. In particular, the phase 3 work described there plans to
lift memory backends into QEMU Objects. After this work, command
line generation will be refactored, and, full NUMA support be ported
to runtime-rs.
This commit also adds the first command-line generator unit tests for
this file to cover the new RAM backend behavior.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
Flip the runtime-rs NVIDIA GPU configs (plain/tdx/snp) from the monolithic
image to the driver-agnostic nvidia base boot image plus a cold-plugged,
driver-versioned gpu extension mounted at /run/kata-extensions/gpu.
Confidential runtime-rs configs additionally cold-plug the CoCo
guest-components extension and enforce the nvidia base dm-verity hash.
The Go runtime keeps booting the monolithic nvidia-gpu / nvidia-gpu-confidential
images, mirroring the CoCo split where runtime-rs is the first-class citizen and
Go stays on the monolithic layout.
Add the IMAGE{NAME,PATH}_NV_{BASE,EXTENSION} and NVIDIAGPUEXTENSIONVERITYPARAMS
make vars (runtime-rs only), and read the nvidia base + gpu-extension root
hashes into runtime-rs's shim-v2 opts while the Go opts keep reading the
monolithic nvidia-gpu / nvidia-gpu-confidential hashes.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Add awaitgroup to workspace dependencies at 0.7.0 and switch both
rustjail and virt_container from local pins to workspace = true.
No API changes required — WaitGroup::new(), .worker() and .wait()
are unchanged across this range.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bump workspace sha2 to 0.11.0 and migrate the local pins in
src/agent/Cargo.toml and src/libs/kata-types/Cargo.toml to
workspace = true. No API changes required — the Digest trait
interface is unchanged across this range.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Some are format expectation changes in 1.95, but
I think some are just missing fmts that our CI doesn't
check.
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Remove redundant `.into_iter()` call in `Vec::from_iter()` argument in
dragonball and firecracker's `inner_hypervisor.rs`, as flagged by the new
`clippy::useless_conversion` lint in Rust 1.95.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Rust 1.95's clippy introduces new `collapsible_match` lints for `if`
blocks nested inside match arms that can be expressed as match guards.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
The CLH runtime-rs config template uses @CONFIG_CLH_IN@ in its
source-file comment, but CONFIG_CLH_IN was missing from the generated
template variables.
Add it to USER_VARS so the generated config records the template path
instead of keeping the literal placeholder.
Fixes: #12941
Signed-off-by: WaterWhisperer <waterwhisperer24@qq.com>
virtio-mem is enabled on s390x, where memory hotplug goes through a
virtio-mem-ccw device set up during VM initialization. That device --
and the later resize -- require a memory hotplug region (a non-zero
maxmem/slots on the QEMU command line).
The runtime-rs command line generator, however, zeroes maxmem/slots
whenever the guest uses the shared /dev/shm memory-backend with a
non-nvdimm rootfs (the s390x case: virtio-blk-ccw rootfs). With no
hotplug region reserved, two things broke on s390x:
* setup_virtio_mem failed VM start with "the configuration is not
prepared for memory devices, consider specifying the maxmem option";
* with virtio-mem unavailable, memory resize fell back to pc-dimm,
which is not a valid device model on s390x, breaking
TestContainerMemoryUpdate:
'pc-dimm' is not a valid device model name
Keep the hotplug region when virtio-mem is enabled, mirroring the Go
runtime which reserves maxmem and hotplugs via virtio-mem-ccw on s390x.
This lets setup_virtio_mem succeed at boot and makes memory resize use
virtio-mem instead of pc-dimm.
Also guard setup_virtio_mem behind QemuCmdLine::has_memory_hotplug_region()
as a defensive fallback: if some configuration still ends up without a
hotplug region, skip virtio-mem setup (like static-sizing arches such as
arm64) rather than failing VM start.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
The container create flow forced every non-pod-container to the
"pod_sandbox" type. Standalone engines (Docker/nerdctl/podman) surface
as SingleContainer, so they were mislabeled as pod sandboxes.
The agent skips CDI device injection when the container type is
"pod_sandbox", so the NVIDIA CDI edits carried in the "cdi.k8s.io/*"
annotations were never applied and the GPU userspace (e.g. nvidia-smi)
was missing in the guest. Emit the actual container type instead, which
matches the Go runtime and lets the agent inject CDI devices for the
single-container flow.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <noreply@cursor.com>
The kubelet PodResources API is only available under Kubernetes. For
single-container engines (Docker/nerdctl/podman) the CDI runtime applies
the device's containerEdits directly to the OCI spec, so the VFIO nodes
(e.g. /dev/vfio/devices/vfio0) show up in linux.devices instead.
Discover those nodes from the OCI spec in addition to the PodResources
API and feed both into the same cold-plug path, de-duplicating by host
path. This reuses the existing Kubernetes machinery so GPU passthrough
works for single containers with no changes to device handling.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <noreply@cursor.com>
A discrete GPU usually shares its IOMMU group with an audio function
(e.g. NVIDIA 02:00.1). Cold-plugging every function in the group made
QEMU emit a vfio-pci/pcie-root-port/iommufd triple per function while
reusing the GPU's root-port and IOMMUFD object ids, so QEMU aborted with
a duplicate-id error before it was reachable over QMP.
Apply the existing IOMMU_IGNORE classification while discovering the
group so audio controllers and bridges are pruned, leaving only the
passthrough-capable device(s). Also fix filter_bridge_device to parse
the sysfs class attribute as hex; the previous decimal parse always
failed, which is why the filter never removed anything.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <noreply@cursor.com>
Set the new pci_path field in cloud-hypervisor network test config so
unit tests compile with the updated NetworkConfig struct.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
Persist and forward the hot-plugged NIC guest PCI path so the agent can
resolve sysfs location and update interfaces reliably.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
Network interface hot-plug places the NIC on the pcie-pci-bridge nested
under a root port. Track the bridge slots already occupied (queried via
query-pci) and reserve bridge slot ranges correctly so repeated NIC
hot-plug operations do not collide on the same bridge slot.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
Network interface hot-plug on Q35 with OVMF needs a hot-pluggable PCIe
slot to attach the NIC to after boot. Add the nested root-port plus
pcie-pci-bridge topology and the related QEMU argument ordering so a
network device can be hot-plugged into the bridge.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
Update hyper to 1.10.1 and hyperlocal to 0.9.1 (required for hyper 1.x
compatibility). Add http-body-util 0.1, hyper-util 0.1 and bytes 1.0 as
workspace dependencies.
API changes applied across shim-interface, runtimes, hypervisor
(firecracker) and resource (nydus_client) crates:
- hyper::Body → http_body_util::Full<Bytes> for outgoing bodies
- hyper::body::Incoming for incoming server request bodies
- hyper::Client → hyper_util::client::legacy::Client
- hyper::Server + make_service_fn → TcpListener loop +
hyper_util::server::conn::auto::Builder (kata-ctl http_server)
- hyper::server::conn::Http → hyper::server::conn::http1::Builder
with hyper_util::rt::TokioIo wrapper (runtimes shim_mgmt server)
- hyper::body::to_bytes() → BodyExt::collect().await?.to_bytes()
- Client::unix() now requires explicit body type parameter Full<Bytes>
- Drop removed 'stream' feature flag from hyper dependency declarations
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Integrate virtio-mem into memory hotplug and hotunplug operations:
- Modified hotplug_memory() to automatically detect virtio-mem device
and use resize instead of pc-dimm hotplug
- Modified hotunplug_memory() to use virtio-mem resize for memory
decrease with saturating_sub to prevent underflow
- Modified hotplugged_memory_size() to account for virtio-mem devices
- Falls back to pc-dimm when virtio-mem is not available
This completes the virtio-mem integration, enabling dynamic memory
management with virtio-mem-ccw on s390x while maintaining full
backward compatibility with pc-dimm.
Assisted-by: IBM Bob
Signed-off-by: Annu Sharma <annu-sharma@ibm.com>
Call setup_virtio_mem() during VM startup when enable_virtio_mem flag
is set:
- Added setup call after QMP connection is established
- Proper error handling with context
Assisted-by: IBM Bob
Signed-off-by: Annu Sharma <annu-sharma@ibm.com>
The `hotplug_vfio_on_root_bus` configuration option is no longer needed
in the runtime-rs.
Remove the option from:
- `DeviceInfo` struct and its `hotplug_vfio_on_root_bus` field
- `PCIeTopology` struct and its construction in `topology.rs`
- `HypervisorInfo` struct and its `hotplug_vfio_on_root_bus` field
- `KATA_ANNO_CFG_HYPERVISOR_HOTPLUG_VFIO_ON_ROOT_BUS` annotation constant
and its handler in `Annotation::apply()`
- DragonBall validation check in `ConfigPlugin::adjust_config()`
- All runtime-rs TOML config templates (qemu, fc, nvidia GPU variants)
- Test fixture TOML files
Update the documentation having a reference to it.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
During the transition to composable (base + extension) CoCo images, run the
two runtimes on different image layouts so CI exercises both paths via
the existing qemu-{snp,tdx,coco-dev} (Go) and -runtime-rs (Rust) shims:
- runtime-rs (Rust) CoCo templates use the standard base image plus a
CoCo extension extra_image:
image = "@IMAGEPATH@" (was @IMAGECONFIDENTIALPATH@)
[[hypervisor.qemu.guest_extension_images]]
name = "coco"
path = "@COCOIMAGEPATH@"
verity_params = "@COCOVERITYPARAMS@"
COCOIMAGENAME/COCOIMAGEPATH/COCOVERITYPARAMS are added to the
runtime-rs Makefile only.
- runtime (Go) CoCo templates keep the monolithic confidential image
(@IMAGECONFIDENTIALPATH@) and pull rootfs-image-confidential.
shim-components.json reflects this: Go CoCo shims depend on
rootfs-image-confidential while the runtime-rs CoCo shims depend on
rootfs-image + rootfs-image-coco-extension.
shim-v2/build.sh feeds each runtime its own dm-verity params: Rust gets
the measured base image hash (@KERNELVERITYPARAMS@) plus the extension hash
(@COCOVERITYPARAMS@); Go gets the monolithic confidential image hash
(@KERNELVERITYPARAMS@). This is wired per make invocation so the same
@KERNELVERITYPARAMS@ placeholder resolves correctly for each.
Once the split path is validated we can flip the Go templates too and
drop the monolithic confidential image.
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Add a serial_override field to BlockConfig and DeviceVirtioBlk so that
extension images get a deterministic QEMU serial (extension-<name>) instead of
the auto-generated image-<id>. This lets the guest discover each extension
via /dev/disk/by-id/virtio-extension-<name>.
Wire up the full cold-plug path for guest_extension_images:
- sandbox.rs: iterate boot_info.guest_extension_images, create read-only
BlockConfig entries with the correct serial_override, and push them
as ResourceConfig::GuestExtensionImage.
- resource lib.rs / manager_inner.rs: handle the new GuestExtensionImage variant
by delegating to the existing block device path.
- cmdline_generator.rs: use serial_override when present for the QEMU
serial= parameter; append kata.extension.<name>.verity_params=... to the
kernel command line for each extra image.
- inner.rs: propagate serial_override from BlockConfig to the cmdline
generator's add_block_device().
Signed-off-by: Fabiano Fidêncio <ffidencio@nvidia.com>
Assisted-by: Cursor <cursoragent@cursor.com>
Update the workspace thiserror dependency to 2.0.18 and
normalize direct workspace crate pins to use the workspace
version.
Fix thiserror 2.x format-string breakage in Dragonball by
replacing mixed positional/implicit arguments in #[error(...)]
attributes with explicit named arguments.
Generated-by: IBM Bob
Signed-off-by: stevenhorsman <steven@uk.ibm.com>
This commit enhances the VFIO-AP testing suite by adding
support for cold-plug testing in runtime-rs and updating
configuration files to support the new cold_plug_vfio parameter.
Changes include:
1. Configuration updates:
- Added cold_plug_vfio parameter to configuration-qemu-runtime-rs.toml.in
with default value "no-port" (disabled)
- Added cold_plug_vfio parameter to configuration-qemu-se-runtime-rs.toml.in
with value "root-port" (enabled for Secure Execution)
2. Test enhancements:
- Updated setup_hotplug() to explicitly set cold_plug_vfio to "no-port"
for runtime-rs to ensure hotplug-only mode
- Implemented setup_coldplug() for runtime-rs (previously unsupported)
to enable cold-plug testing with "root-port" configuration
- Added new test case (Test 4) for runtime-rs VFIO-AP cold-plug
functionality using zcrypttest validation
This enables comprehensive testing of both hot-plug and cold-plug VFIO
device assignment scenarios for s390x CEX devices in runtime-rs.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
Add support for cold-plugging raw VFIO devices in standalone
container scenarios (e.g., `ctr --device /dev/vfio/0`) where
devices are specified directly in the OCI spec rather than
through K8S CDI/device plugins.
This implements a fallback path that:
- Reads linux.devices from the OCI spec in the container bundle
- Identifies character devices under /dev/vfio
- Cold-plugs them before VM boot using the configured cold_plug_vfio mode
- Handles VFIO-AP devices specially by using NoPort topology
- Mirrors the Go runtime's coldOrHotPlugVFIO() behavior
The implementation:
- Adds prepare_coldplug_raw_vfio_devices() method to VirtSandbox
- Exports is_vfio_ap_device() helper for device type detection
- Integrates with existing CDI device cold-plug flow
- Only activates when cold_plug_vfio is configured (not "no-port")
- Skips processing when bundle path is unavailable or OCI spec missing
Plus, update resource manager:
- Skipping hotplug for cold-plugged mediated AP devices
- Handling the AP devices to get exposed to the agent
This enables VFIO device passthrough for standalone containers while
maintaining compatibility with Kubernetes pod resource API workflows.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
Add runtime-rs support for s390x VFIO-AP mediated devices across
QEMU device creation, hotplug/coldplug flows, and agent device
translation.
Introduce a dedicated vfio-ap QEMU device generator using the sysfsdev
path and route mediated AP devices through it instead of the PCI VFIO
path. Skip PCI-specific guest path handling for these devices since
they do not use PCI root ports or guest PCI addresses.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
This commit adds a fallback mechanism in `get_image_reference()` to
handle SingleContainer scenarios where no container type annotation
is present.
The issue occurs when standalone container runtimes (like nerdctl)
create containers without the Kubernetes container type annotation.
In such cases, `container_type_with_id()` returns `SingleContainer`
as the default, but `get_image_reference()` previously only checked
for image names when a container type annotation was explicitly set
to either PodSandbox or PodContainer.
This caused image reference lookups to fail for standalone containers,
even though the image name annotations (io.kubernetes.cri.image-name
or io.kubernetes.cri-o.ImageName) were present in the spec.
The fallback logic now checks for image name annotations directly
when no container type annotation is found, supporting both:
- io.kubernetes.cri.image-name (standard CRI)
- io.kubernetes.cri-o.ImageName (CRI-O specific)
This maintains backward compatibility with Kubernetes pod scenarios
while enabling support for standalone container runtimes that don't
provide container type annotations.
Test cases have been added to verify the fallback behavior for both
CRI and CRI-O image name annotations in SingleContainer scenarios.
Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
Pass block-device discard support through the runtime-rs QEMU stack.
Block device configuration now reaches both QEMU startup and hotplug
paths. The backend receives discard=unmap, and virtio-blk frontend
devices advertise discard support when requested. The SCSI hotplug path
keeps its existing frontend arguments.
Signed-off-by: Manuel Huber <manuelh@nvidia.com>
Assisted-by: OpenAI Codex <codex@openai.com>
