Add option to resize disk.img to actual DataVolume size

[gites]

Is this a BUG REPORT or FEATURE REQUEST?:

/kind enhancement
There should be an option allowing to resize disk.img to actual DataVolume size created for that image file. This would be beneficial in a situation when one wants to use the same VM image for different services/environments with different storage requirements (Ex.: service A need 50GB, service B 75GB, VMs on dev need 25GB, on prod 100GB, etc). Option could be trigered by adding resize flag to DataVolumeTemplate:

  dataVolumeTemplates:
      spec:
        resize: true

By default resize should be set to false.

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• CDI version (use kubectl get deployments cdi-deployment -o yaml):
• Kubernetes version (use kubectl version):
• Cloud provider or hardware configuration:
• Install tools:
• Others:

[j-griffith]

I'm not sure I understand the idea here. If I need a 50G PVC I should request that, if I need a 100G PVC then I should request that. IMO I would expect a user to have an understanding of what they're doing and size requirements for their image. In other words I would expect them to calculate things correctly. Sure, I may have different environments that I want different sized PVCs backing the same vm image for, but why wouldn't I expect the user to explicitly ask for that?

[gites]

This is not about PVC size, but rather on the disk size that running VM will see. If you request 50G PVC and you put on the PVC official Ubuntu or Fedora cloud image and then login to the VM running from that image you will have only ~4G available. If you will request 100G PVC, the VM will still have only ~4G available.

To fix that, the size of the downloaded image needs to be adjusted ( qemu-img resize) so all space from PVC can be available for VM.

[j-griffith]

@gites thanks for the explanation. I'll comment in the PR, thanks!

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale