-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Containerd aufs/devmapper/zfs snapshotters removed from May 2023 releases #7660
Comments
Just noting here that we did have a long series of releases that included the zfs snapshotter. That was unintentionally added when we moved to building standalone containerd, so we didn't initially notice when it went away when we moved containerd back into the multicall binary. Some folks had come to rely on its presence. |
I can accept migrate off zfs snapshotter to zfs vol if I know how, (zfs 2.2 support overlayfs), but before this, I hope I can use the stable version of k3s 😭 |
This will be resolved in the June releases. |
Validated using commit id b66a118 from master branch
skip loading plugin due to non zfs filesystem
|
Some VM based workloads do not have the capability of using a shared filesystem to give the guest access to the container rootfs, which is stored on the host side.
This case described above is exactly what happens when we talk about Kata Containers using Firecracker as VMM, Kata Containers running Confidential VMs (such as Intel TDX, AMD SEV, AMD SNP, IBM SE).
Enabling this on the k3s side is an onliner, here:
k3s/pkg/containerd/builtins_linux.go
Line 27 in 7c0a768
Having this enabled by default would help a lot users of VM based workloads.
The text was updated successfully, but these errors were encountered: