You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allowing override default vcpu count/mem setting of firecracker vm through OCI annotation #834
When create container using firecracker-ctr directly, we always use default vcpu/mem setting (i.e., 1C 128MB) for firecracker vm at present. Allowing users to specify desired vcpu count and memory size via oci annotation is probably a simple way to fix the issue.
Thank you for your request. Can you explain a bit about the use case you want to solve.
I am still reading the architecture to understand it better, but i am not sure connecting the vm specs with container specs is a good idea based on the single vm/host architecture. We can have multiple containers running in the vm but not necessarily requiring multiple vm for the use case.
I would say we decouple the vm creation from the run command and have it in a different CLI if that serves the purpose.
Yes, I agree that this doesn't apply to multiple containers in a single VM scenario. My use case involves using firecracker-containerd without pre-created VMs, which I believe is already supported by firecracker-containerd, except for configuring VM size. This would be helpful for quickly creating several containers for testing using a simple script.
Having this feature in a separate CLI would also work, but it might require more effort than the current proposal.
My concern is the proposal doesn't fit the current design considerations. Another option is to make the vm options of vcpu and mem configurable. Another option can be using the config.go to specify the vm specifications. It is a singular source of configuration which would ensure non intended changes are not made while execution of ctr commands.
Will discuss this with others and if this proposal is agreeable to you (once i can confirm), will be happy to accept a PR for this and review it.
Activity
Shubhranshu153 commentedon Oct 22, 2025
Hi @sjtufl ,
Thank you for your request. Can you explain a bit about the use case you want to solve.
I am still reading the architecture to understand it better, but i am not sure connecting the vm specs with container specs is a good idea based on the single vm/host architecture. We can have multiple containers running in the vm but not necessarily requiring multiple vm for the use case.
I would say we decouple the vm creation from the run command and have it in a different CLI if that serves the purpose.
sjtufl commentedon Oct 22, 2025
Hi @Shubhranshu153 ,
Yes, I agree that this doesn't apply to multiple containers in a single VM scenario. My use case involves using firecracker-containerd without pre-created VMs, which I believe is already supported by firecracker-containerd, except for configuring VM size. This would be helpful for quickly creating several containers for testing using a simple script.
Having this feature in a separate CLI would also work, but it might require more effort than the current proposal.
Shubhranshu153 commentedon Oct 22, 2025
My concern is the proposal doesn't fit the current design considerations. Another option is to make the vm options of vcpu and mem configurable. Another option can be using the config.go to specify the vm specifications. It is a singular source of configuration which would ensure non intended changes are not made while execution of ctr commands.
Will discuss this with others and if this proposal is agreeable to you (once i can confirm), will be happy to accept a PR for this and review it.
https://github.com/firecracker-microvm/firecracker-containerd/blob/main/config/config.go
sjtufl commentedon Nov 17, 2025
Yes, I think it partially serves the need. It would allow the VM size to be configurable for this use case.