liquidmetal-dev / flintlock

Lock, Stock, and Two Smoking MicroVMs. Create and manage the lifecycle of MicroVMs backed by containerd.
Mozilla Public License 2.0
537 stars 33 forks source link

Setting root_volume.size_in_mb seems to have no effect #553

Open Callisto13 opened 1 year ago

Callisto13 commented 1 year ago

It would appear we don't actually process that input and resize the volume before mounting.

cf: https://github.com/weaveworks-liquidmetal/cluster-api-provider-microvm/issues/234

Callisto13 commented 1 year ago

This may be tricky to do, and may indeed be something we don't even want to do.

The "base-size" of snapshots created by containerd is 10gb, basically meaning all root volumes attached to microvms will be able to expand up to a max of 10gb. When using with docker most users would end up just attaching additional volumes and using those instead so most did not care about the rootfs size.

[plugins]
  [plugins."io.containerd.snapshotter.v1.devmapper"]
    pool_name = "flintlock-thinpool"
    root_path = "/var/lib/containerd/snapshotter/devmapper"
    base_image_size = "10GB"
    discard_blocks = true

In our case, it is easier to say at the flintlock level that users can "just" supply an additional volume if they need more room, but it it less pleasant at a capmvm level.

being able to override this and expand an indivdual snapshot size for an mvm would be better, but idk if containerd lets us do this.

we could resize the disk after mvm creation

or make the additional volume option easier to use (also right now i dont think additional volumes are actually mounted in and the user has to do it after the fact)

aryan9600 commented 1 year ago

would resizing of the device by updating the dm table to have more byte sectors be a feasible option? according to this, we just need to feed the appropriate size to the table and reload it.

richardcase commented 1 year ago

I'd say let's remove the option and go with the simplest solution, which is to stick to the base size defined when configuring the plugin. And if someone explicitly asks for the ability to resize a volume then we can add the api definition back in and do the work.

alexellis commented 1 year ago

We're using the same approach with actuated. I'm curious if it's possible to get dynamically sized volumes or just the base size when using the devmapper plugin for containerd?

aryan9600 commented 1 year ago

hey @alexellis, could you elaborate on your approach? Do you also resize the volume by increasing the devmappper device and reload the table?

alexellis commented 1 year ago

We just set the size to the largest that will be needed. Since these are CoW that's not a big problem.

But it'd be nicer if there was a consistent way to ask for a certain size at snapshot time in containerd / or the snapshotter.

Thanks for the link for growing a snapshot via dmsetup.. that's a new one for me.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open 60 days with no activity.