feat(hypervisors/firecracker): Add support for read-only flags and multiple block devices in Firecracker VMM

[safiya2610]

Description

In pkg/unikontainers/hypervisors/firecracker.go, Firecracker block drive configuration (FCDrives) currently hardcodes IsRO: false and only marks drives named "rootfs" as root devices. Furthermore, empty paths are not validated, and read-only volume mounts are ignored when generating the /tmp/fc.json configuration for Firecracker microVMs.

As noted by the TODO comment in line 156 (// TODO: Add support for block devices in FIrecracker), Firecracker needs dynamic block device handling to support read-only volumes and multiple attached drives.

Files

• pkg/unikontainers/hypervisors/firecracker.go
• pkg/unikontainers/types/types.go

Expected Behavior

1. MonitorBlockArgs in types.go should include an IsRO bool field to propagate read-only mount status.
2. firecracker.go should parse blockArg.IsRO dynamically into FirecrackerDrive.IsRO.
3. Empty host paths should be filtered out to prevent invalid JSON config generation.
4. Fallback root device logic (IsRootDev = true) should apply to the primary drive when "rootfs" ID is absent.
5. Add table-driven unit tests in firecracker_test.go to verify Firecracker JSON generation for single, multiple, and read-only block devices.

Verification

1. Run go test -v ./pkg/unikontainers/hypervisors/...
2. Verify Firecracker JSON config generation with read-only and multi-drive specs.

[safiya2610]

/kind feature

[safiya2610]

@cmainas Hi, I have raise this issue, can you please confirm the issue.

[KHARSHAVARDHAN-eng]

Hi @safiya2610, I’m interested in working on this issue. Are you already planning to implement it, or would it be okay for me to take it up?

[safiya2610]

Hi @safiya2610, I’m interested in working on this issue. Are you already planning to implement it, or would it be okay for me to take it up?

I'm working on this.

[KHARSHAVARDHAN-eng]

@safiya2610 , fine .. i will work on other issue...

[Nachiket-Roy]

Seems related to #315, check that too. Also do tell about your approach to resolve it.

[safiya2610]

Seems related to #315, check that too. Also do tell about your approach to resolve it.

My approach will be:

1. I will Update the Data Structure (pkg/unikontainers/types/types.go)
   Add an IsRO bool field to the MonitorBlockArgs struct. This will allow the configuration to carry the read-only flag for each block device through the codebase to the hypervisor setup phase.

type MonitorBlockArgs struct {
	ID        string
	Path      string
	ExactArgs string
	IsRO      bool // <- Add this field
}

2. Then Update Configuration Parsing (pkg/unikontainers/hypervisors/firecracker.go)
   In the BuildExecCmd method, I need to update how FCDrives is populated to handle the new field, empty paths, and rootfs fallbacks:
   Filter Empty Paths: Inside the bArgs loop, immediately continue if blockArg.Path == "" to avoid generating malformed drives in the JSON.
   Propagate IsRO: Map the newly added blockArg.IsRO field to aBlock.IsRO (replacing the hardcoded false).
   Root Device Fallback: Do a quick pre-scan over bArgs to see if any drive has ID == "rootfs".
   If a "rootfs" drive is explicitly declared, mark it as IsRootDev: true as usual.
   If no "rootfs" drive exists, mark the very first valid block device as IsRootDev: true.

3. Add Unit Tests (pkg/unikontainers/hypervisors/firecracker_test.go)
   i will add a new table-driven test case to TestFirecrackerBuildExecCmd to verify these three behaviors simultaneously:

[safiya2610]

Should I proceed with this, or any change in approach is needed

[Nachiket-Roy]

Hey #908 might be worth a look - similar problem, different VMM.

[safiya2610]

Hey #908 might be worth a look - similar problem, different VMM.

sure