The image file's Virtual image size change when upload to dv with different size

[Longchuanzheng]

What happened: A clear and concise description of what the bug is In advance: the img file is a .mp4 file before ,I change the suffix to qcow2.

When I update it to a 1G dv with https://XXX/v1alpha1/upload-async it return Virtual image size is 1G+

While I update it to a 2G dv, it also return Virtual image size is 2G+

What you expected to happen: A clear and concise description of what you expected to happen.

I am puzzled why Virtual image size can change.IMO, It is get by qemu-img info.

By the way, this file just has suffix .qcow2. I think we should return fmt error or something like it.

How to reproduce it (as minimally and precisely as possible): Steps to reproduce the behavior. Maybe you can reproduce it by change a mp4 file suffix to .qcow2, and upload it with v1alpha1/upload-async.

1. find a .mp4 file ,change it suffix to .qcow2
2. create dv and token

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: zal-test-5
  namespace: zal
spec:
  source:
    upload: {}
  pvc:
    accessModes:
      - ReadWriteMany
    resources:
      requests:
        storage: 10G
    storageClassName: rbd-ssd
    volumeMode: Block

3. uplod file with

curl -v --insecure -H "Authorization: Bearer token" --data-binary @xxx/nlw-ssh.qcow2 https://ip/v1alpha1/upload-async -g

Additional context: Add any other context about the problem here.

Environment:

• CDI version (use kubectl get deployments cdi-deployment -o yaml): 1.53
• Kubernetes version (use kubectl version): N/A
• DV specification: N/A
• Cloud provider or hardware configuration: N/A
• OS (e.g. from /etc/os-release): N/A
• Kernel (e.g. uname -a): N/A
• Install tools: N/A
• Others: N/A

[awels]

So we do detect if something is a valid qcow2 file and do a conversion to raw as this is what KubeVirt uses. If we can't detect that the format is qcow2, we assume it is raw already as a disk can contain anything. We resize image to fit the size of the requested PVC, it makes no sense to have a 1G virtual disk size, on a 10G PVC, it is a waste of space. So we resize the virtual disk size to match the size of the PVC.

Now for the error you are seeing, if you upload to a filesystem PVC, there will be some filesystem overhead and the actual available space on the PVC might be less than the requested size. If you are manually creating the PVC then you are likely not taking into account the filesystem overhead of the PVC. Many providers will simply make a block device of the requested size and then put a filesystem on it. So the actually available space is smaller than the requested size. While we resize the disk image to the requested size of the DataVolume. If you use the provided DataVolume APIs we take this into account and request a larger PVC that will accommodate the proper size.

[Longchuanzheng]

@awels Thanks for your explanation. I have used block pvc and the required available stroage is equeal to PVC size as you mentioned. IMO, the error is in ValidatePause. So I think the problem is in TransferScratch phase, while I can't find the code where cdi resize the raw file.

[awels]

The resize happens after the transfer to the target PVC and only if it is a filesystem PVC, since you cannot resize a block PVC. If you are using a block PVC, then we need to investigate what exactly we are doing, there might be a bug lurking in there. Can you give us the datavolume you used to create the PVC, or at least the PVC yaml of the target PVC?

[Longchuanzheng]

By the way, this happens in cdi 1.53. I will find a lastet version cdi to retest.

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"cdi.kubevirt.io/v1beta1","kind":"DataVolume","metadata":{"annotations":{},"name":"zal-test-5","namespace":"zal"},"spec":{"pvc":{"accessModes":["ReadWriteMany"],"resources":{"requests":{"storage":"10G"}},"storageClassName":"rbd-ssd","volumeMode":"Block"},"source":{"upload":{}}}}
  creationTimestamp: "2024-01-31T07:14:04Z"
  generation: 79187
  name: zal-test-5
  namespace: zal
  resourceVersion: "241668222"
  selfLink: /apis/cdi.kubevirt.io/v1beta1/namespaces/zal/datavolumes/zal-test-5
  uid: f74f9f84-d73b-4587-b153-d3692ec4796f
spec:
  pvc:
    accessModes:
    - ReadWriteMany
    resources:
      requests:
        storage: 10G
    storageClassName: rbd-ssd
    volumeMode: Block
  source:
    upload: {}
status:
  claimName: zal-test-5
  conditions:
  - lastHeartbeatTime: "2024-01-31T07:14:07Z"
    lastTransitionTime: "2024-01-31T07:14:07Z"
    message: PVC zal-test-5 Bound
    reason: Bound
    status: "True"
    type: Bound
  - lastHeartbeatTime: "2024-02-02T02:56:56Z"
    lastTransitionTime: "2024-01-31T07:14:04Z"
    reason: TransferRunning
    status: "False"
    type: Ready
  - lastHeartbeatTime: "2024-01-31T07:14:17Z"
    lastTransitionTime: "2024-01-31T07:14:17Z"
    reason: Pod is running
    status: "True"
    type: Running
  phase: UploadReady
  progress: N/A

upload server log:

[xx@node01 ~]$ kubectl logs -n zal cdi-upload-zal-test-5
I0131 07:14:17.536599       1 uploadserver.go:74] Running server on 0.0.0.0:8443
I0131 07:14:59.123067       1 uploadserver.go:325] Content type header is ""
I0131 07:14:59.123097       1 data-processor.go:379] Calculating available size
I0131 07:14:59.123879       1 data-processor.go:387] Checking out block volume size.
I0131 07:14:59.123887       1 data-processor.go:399] Request image size not empty.
I0131 07:14:59.123898       1 data-processor.go:404] Target size 10G.
I0131 07:14:59.123996       1 data-processor.go:282] New phase: TransferDataFile
I0131 07:14:59.124604       1 util.go:192] Writing data...
I0131 07:14:59.666164       1 data-processor.go:282] New phase: ValidatePause
I0131 07:14:59.666183       1 data-processor.go:288] Validating image
E0131 07:14:59.671142       1 data-processor.go:278] Virtual image size 10737418240 is larger than the reported available storage 10000000000. A larger PVC is required.
E0131 07:14:59.671166       1 uploadserver.go:337] Saving stream failed: Virtual image size 10737418240 is larger than the reported available storage 10000000000. A larger PVC is required.

[awels]

Note the reported size is 10Gi, and the PVC size is 10G (no i). Its the difference between 10 * 1000000000 and 10 * 1024 * 1024 * 1024. Make sure your source image is 10G and not 10Gi or create your PVC as 10Gi.

[Longchuanzheng]

Thanks this clarifies the direction. While the source image is 144Mi just mentioned above. Now the problem is I upload a 144Mi image to a 10G DV(PVC), the Virtual image size(I think it is get by qemu-img info) is change in upload process. As you said cdi will not resize image with block PVC.

[awels]

So if you run qemu-img info <source> locally it tells you the size is 144mi for the virtual size?

[Longchuanzheng]

So if you run qemu-img info <source> locally it tells you the size is 144mi for the virtual size?

Yes. Saving stream failed: Virtual image size 10737418240 is larger than the reported available storage 10000000000. A larger PVC is required. IMO, This error means the output of qemu-img info <source> is 10737418240 in upload-server pod.

[aglitke]

@Longchuanzheng Just checking in on this issue. Were you able to resolve your issue and get your questions answered? If so, I'd like to close this issue.

[Longchuanzheng]

@aglitke .Hi, sorry, I've been busy with other things recently. You can close this issue, If I find other things new, I will reopen it.

[alromeros]

@aglitke .Hi, sorry, I've been busy with other things recently. You can close this issue, If I find other things new, I will reopen it.

Thanks @Longchuanzheng! closing this as discussed.