Recording: https://youtu.be/Uw2pfd-rutI
Agenda:
[akalenyu] VMState PVC improvements
Additional PVC per VM significantly increases the number of PVCs (storage and platform limits)
Many storage vendors have minimum size limits for PVCs (1G or even 50G) but our current VMState data requires only tens of MB. This means we are wasting a lot of storage capacity leading to higher costs.
Virt-handler starts managing PVC per node
Details (?)
CSI driver
Hostpath provisioner may be doing something very similar
Better idea - driver that during attachment would present data from kopia repository - which can be backed by many entities (bucket/another vol/…)
Eliminates hpps topology issue
More functionality to allow integration with cloud vaults? Is this even needed? Similar to external KMS for ceph CSI
Driver that pools the storage using NFS? (RWX FS)
Third option ?
Serve over network, kubevirt deploys tpm repository
[mhenriks] challenge 1 PVC -> 1 Disk
Filesystem - leave some space
Block - partition
Upgrade consideration
With the CSI driver approach, we have to smooth out the edges wrt storage live migration of backend state PVCs (semantics and or functionality)
With multiple disks per PVC some more thought is required
Has to be part of design
Reflection of backend PVC state in VM spec
I think we should reflect it in the spec similarly to API server token in pods
https://groups.google.com/g/kubevirt-dev/c/Fidytryw49c/m/4czUY34PCgAJ
[akalenyu] kubevirt/cdi golang 1.24 blocked over (yet another issue with) bazel
CDI may get away slightly easier
Triage