firecracker-microvm / firecracker-microvm/firecracker-go-sdk
Errors configuring Jailer with containerd snapshot images for Kernel and/or Disks
- Dominant language
- Go
- Stars
- 672
- Forks
- 166
- PR merge metrics
- No merged PRs in 30d
Description
We are attempting to run Firecracker microVMs with containerd snapshot images. We encounter errors like:
```
failed to start machine: link /home/vagrant/localdev/assets/kernel/5.15.0-1022-azure /tmp/nomad_driver_harness-3516676135/firecracker-1.2.0/39f96f66-58e9-1ff0-acfd-68d02f25c754/root/5.15.0-1022-azure: invalid cross-device link
```
This is because the `LinkFilesHandler` from the `NaiveChrootStrategy` wants to link the incoming kernel path (and disks, etc.) into the firecracker's "jailed" chroot directory, but the disks are their own devices already and cannot be linked in this way.
Is the recommended way to deal with this, defining a new strategy and set of handlers specific to this use case? If so, could someone provide pointers on what that might look like? We've attempted bind-mounting the image files into the chroot directory, as well as building the snapshot images directly in each chroot directory instead of linking, but neither approach has worked so far.
Happy to provide additional context if needed to further define this use case.
Contributor guide
Research direction
Start by reading the NaiveChrootStrategy and its LinkFilesHandler, focusing on how incoming kernel and disk paths are handled inside the jailed chroot. Investigate the reported invalid cross-device link with containerd snapshot images and the attempted bind-mount approach; the work is complete when the supported strategy or handler approach for these images is clearly established.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100