Allowing override default vcpu count/mem setting of firecracker vm through OCI annotation

[sjtufl]

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.

fctr run \
    --snapshotter devmapper \
    --runtime aws.firecracker \
    --cpu-quota 20000 \
    --cpu-period 100000 \
    --memory-limit 536870912 \
    --annotation aws.firecracker.vm.vcpu-count=2 \
    --annotation aws.firecracker.vm.mem-size-mib=1024 \
    --net-host \
    -d \
    docker.io/library/nginx:1.25 \
    $CONTAINER_NAME

I can create a PR to support this use case if you think it makes sense.

[Shubhranshu153]

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]

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]

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]

Yes, I think it partially serves the need. It would allow the VM size to be configurable for this use case.