Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting root_volume.size_in_mb seems to have no effect #553

Open
Callisto13 opened this issue Oct 11, 2022 · 7 comments · May be fixed by #718
Open

Setting root_volume.size_in_mb seems to have no effect #553

Callisto13 opened this issue Oct 11, 2022 · 7 comments · May be fixed by #718
Labels
kind/bug Something isn't working lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@Callisto13
Copy link
Member

Callisto13 commented Oct 11, 2022

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

cf: liquidmetal-dev/cluster-api-provider-microvm#234

@Callisto13 Callisto13 added the kind/bug Something isn't working label Oct 11, 2022
@Callisto13 Callisto13 self-assigned this Oct 11, 2022
@Callisto13
Copy link
Member Author

Callisto13 commented Oct 11, 2022

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)

@Callisto13 Callisto13 removed their assignment Dec 13, 2022
@aryan9600
Copy link
Contributor

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
Copy link
Member

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.

@aryan9600 aryan9600 linked a pull request May 25, 2023 that will close this issue
4 tasks
@alexellis
Copy link

alexellis commented May 26, 2023

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
Copy link
Contributor

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

@alexellis
Copy link

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
Copy link
Contributor

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

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jul 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
No open projects
Status: Ready to work on
Development

Successfully merging a pull request may close this issue.

4 participants