You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe:
In multi-tenant clusters with storage quotas, importing a virtual machine adds additional friction to the user experience due to the temporary amount of persistent storage required.
When importing a virtual machine on v1.60.3 with volume mode block (as to not add filesystem overhead to the equation) the process temporarily takes 3x the storage requested on the dataVolume to complete the import.
For example, with the given quota in an otherwise empty namespace:
This is because 3 volumes are made during the import process:
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
debian-disk Pending rook-ceph-nvme <unset> 61s
prime-fe3207de-d67c-4c42-a95b-d7c59c8b2401 Bound pvc-747076a3-afb4-4793-be1c-a1751ce99f03 20Gi RWO rook-ceph-nvme <unset> 61s
prime-fe3207de-d67c-4c42-a95b-d7c59c8b2401-scratch Bound pvc-f9552aec-4435-440a-bf7d-76f77af30b4e 20Gi RWO rook-ceph-nvme <unset> 48s
Would it be possible to reduce this down to 1 or 2 volumes?
Describe the solution you'd like:
Some ideas I have to do this:
Give the option for scratch space to exist on emptyDir. I read though the scratch space doc and I understand the reasoning behind it. But it would be nice to have the option to use emptyDir and take the risk of not having enough space to avoid a PVC allocation. Our storage class is backed by Rook RBD so it's a ReadWriteOnce only setup.
Reduce the number of active PVCs to 2. Can we wait on creating debian-disk until we've destroyed prime-fe3207de-d67c-4c42-a95b-d7c59c8b2401? Without doing Start design doc #1 that would reduce the number of volumes to 2. So users would only need to ask for 2x the quota instead of 3x.
Regardless of the implementation, the ideal end-state would be to have some path where users can ask for 20Gi of storage quota and do a CDI import that only requires 20Gi of storage.
Describe alternatives you've considered:
Right now users have to request 3x the amount of storage they need, and sometimes a bit more than 3x if they are using the Filesystem mode with the default overhead.
The text was updated successfully, but these errors were encountered:
Another option could be to provision in a cdi owned "system" populator namespace where a higher, shared storage quota could be set. As a final step, the prepared PV would be bound to the target PVC in the target namespace. Would something like this solve the problem you are seeing? There are some potential security issues with this approach which is why we didn't implement it in this way from the beginning.
I believe so. In that case we'd have some generic storage quota set aside for these operations, within namespace cdi would be ok. If we ran out of disk quota in cdi then it'd just queue up the CDI imports.
That method would also be a better user experience.
Is your feature request related to a problem? Please describe:
In multi-tenant clusters with storage quotas, importing a virtual machine adds additional friction to the user experience due to the temporary amount of persistent storage required.
When importing a virtual machine on v1.60.3 with volume mode
block
(as to not add filesystem overhead to the equation) the process temporarily takes 3x the storage requested on the dataVolume to complete the import.For example, with the given quota in an otherwise empty namespace:
And the following YAML to import a 20Gi Debian Cloud VM:
The following quota is used during the import:
This is because 3 volumes are made during the import process:
Would it be possible to reduce this down to 1 or 2 volumes?
Describe the solution you'd like:
Some ideas I have to do this:
emptyDir
. I read though the scratch space doc and I understand the reasoning behind it. But it would be nice to have the option to use emptyDir and take the risk of not having enough space to avoid a PVC allocation. Our storage class is backed by Rook RBD so it's a ReadWriteOnce only setup.debian-disk
until we've destroyedprime-fe3207de-d67c-4c42-a95b-d7c59c8b2401
? Without doing Start design doc #1 that would reduce the number of volumes to 2. So users would only need to ask for 2x the quota instead of 3x.Regardless of the implementation, the ideal end-state would be to have some path where users can ask for 20Gi of storage quota and do a CDI import that only requires 20Gi of storage.
Describe alternatives you've considered:
Right now users have to request 3x the amount of storage they need, and sometimes a bit more than 3x if they are using the Filesystem mode with the default overhead.
The text was updated successfully, but these errors were encountered: