search

kubevirt / containerized-data-importer

Data Import Service for kubernetes, designed with kubevirt in mind.
Apache License 2.0
428 stars 269 forks source link

qcow2 and virtual size prediction #3456

Open ianb-mp opened 1 month ago

ianb-mp commented 1 month ago

Is your feature request related to a problem? Please describe:

Launching VMs using qcow2 images from 3rd parties presents a dilemma - I don't know what size PVC to allocate in advance. I also don't want to allocate significantly more storage to a VM than necessary. So far, I've just been using trial and error:

  1. allocate a large PVC
  2. launch VM
  3. if the size of the raw image is less than the allocated PVC, then allocate a smaller PVC and relaunch VM using that PVC

Describe the solution you'd like:

It'd be good if I could specify a maximum PVC size that I'm willing to accomodate. The importer would create a temporary PVC of that size to unpack the image into. If the PVC is too small then it throws an error, otherwise a PVC is created that matches the size of the unpacked image and that is used for the datavolume.

Describe alternatives you've considered:

I know I can use qemu-img info to find out the virtual size in advance, but I wondered if this step could be incorporated into CDI.

Additional context: Add any other context or screenshots about the feature request here.

awels commented 1 month ago

That is a good question, and we have given this some thought already. In general we would like to detect the size and just allocate the appropriate size PVC and everyone is happy. There are two sizes in play.

  1. The 'real' size. This is the actual size allocated on the volume
  2. The 'virtual' size. This is the size of the disk inside the VM, we need to allocate a PVC to accommodate this size, since in theory the VM could use up the entire disk, and we need to allow for that. I guess technically there is a 3rd size in play, the size of the image. What would be the ideal situation is that we know the size of the image, create a temporary PVC of that size, download the image to that PVC, do some detection (qemu-img info). And based on that create a new PVC that can hold the virtual size. Then do the conversion step.

The problem is we can't reliably get the size of the image. From some sources we can (registry for instance). Others it is pretty much impossible to reliably get that information. This is the main reason we haven't implemented size detection at this point.

ianb-mp commented 1 month ago

What would be the ideal situation is that we know the size of the image, create a temporary PVC of that size, download the image to that PVC, do some detection (qemu-img info). And based on that create a new PVC that can hold the virtual size. Then do the conversion step.

The problem is we can't reliably get the size of the image

I don't understand why that matters. The solution I proposed doesn't depend on that size being known in advance.

aglitke commented 1 month ago

@arnongilboa since you were looking at size detection in the past would you care to comment on this idea? One concern that was raised in the sig-storage meeting review of this issue is that this flow could work with DataVolumes but not with the new bare PVC populators approach. The reason this would be difficult in that scenario is that the user needs to create the desired PVC herself and that locks in the size. It would be strange to replace the PVC that was created to initiate the operation with a different PVC later.

arnongilboa commented 4 weeks ago

@aglitke I see no problem supporting this behavior with the new bare PVC populators approach, by using the mutating webhook rendering feature, which already supports rendering PVC missing size in the clone flow. In the old size-detection POC we went the other direction, initially trying small PVCs, and recreating/expanding the PVC with the correct size according to the failure message details.

akalenyu commented 4 weeks ago

I would prefer to avoid automating the trial and error approach, it's very much prone to issues and tbh the use case of not knowing the OS in advance (and thus the size) is a little off to me.

That said, I think that with an approach similar to https://github.com/kubevirt/containerized-data-importer/pull/3103 we could achieve something more dependable to satisfy the use case. So the container disk labels (which give away the OS) can also expose the size.

arnongilboa commented 4 weeks ago

I would prefer to avoid automating the trial and error approach, it's very much prone to issues and tbh the use case of not knowing the OS in advance (and thus the size) is a little off to me.

Unlike the old direction, the idea suggested here is not exactly trial-and-error, as it assumes a "large enough" temporary pvc.

That said, I think that with an approach similar to #3103 we could achieve something more dependable to satisfy the use case. So the container disk labels (which give away the OS) can also expose the size.

How can it be used in http import flow?