(In reply to Vatsal Parekh from comment #0)
> Description of problem:
> Similar to https://bugzilla.redhat.com/show_bug.cgi?id=1674508 but with
> virtctl image-upload, I see same issue with Windows, when uploading a 12G
> Windows.qcow2 to a 30G PVC (enough size to decompress?), the VM boots with
> showing 'No Bootable found' error on the console.
> Unlike the other bug which has a fix related to importer pod, this is
> related image-upload
> 
> Version-Release number of selected component (if applicable):
> 3.11+1.4
> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1.Upload a Windows.qcow2 using virtctl image-upload
> 2.Attach that pvc to a vm and boot it
> 3.
> 
> Actual results:
> No bootable found error
> 
> Expected results:
> Should boot successfully
> 
> Additional info:
> Alex on this bug https://bugzilla.redhat.com/show_bug.cgi?id=1674508
> suggested this will be a different issue so opened a separate bug

Was trying to refer to this bug https://bugzilla.redhat.com/show_bug.cgi?id=1670057

Alex, can you help with what more should we debug here?

Is 12G the "virtual size" of the qcow2 file or the actual file size?  Can you include the output of "qemu-img info" here?

The PVC has to be big enough to support both the physical and virtual sizes of the qcow2 file.

I am trying again with a bigger PVC
But,
- yesterday we got a Windows.qcow2 working on a 22G pvc, which seems contradicting to what you suggest, because it failed with 31G of PVC for me previously
- The upload actually didn't show any error, so is it failing silently if it was not able to extract properly due to lack of disk?

(In reply to Vatsal Parekh from comment #5)
> I am trying again with a bigger PVC
> But,
> - yesterday we got a Windows.qcow2 working on a 22G pvc, which seems
> contradicting to what you suggest, because it failed with 31G of PVC for me
> previously
That 22G pvc was tried using DataVolume, this BZ is for image-upload, but the logic for size of the PVC remains the same right?
> - The upload actually didn't show any error, so is it failing silently if it
> was not able to extract properly due to lack of disk?

More info here:

Using a bigger (50gb) PVC seems like the VM is booting using the virtctl image-upload tool, but there isn't a way to know te size of the PVC.

It seems to be:

```
[root@unified-demo02-master0 RDP]# qemu-img info  /opt/extra/w2k.qcow2 
image: /opt/extra/w2k.qcow2
file format: qcow2
virtual size: 12G (13096714240 bytes)
disk size: 11G
cluster_size: 65536
Format specific information:
    compat: 0.10
```

The Virtual Size of the qcow + the size of the uncompressed img (as we discussed by IRC with @vatsal and @rhrazdil).

In other hand we could use DataVolumeTemplates to boot the VM using something like this:

```
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  annotations:
    name.os.template.cnv.io/win2k12r2: Microsoft Windows Server 2012 R2
  labels:
    kubevirt.io/vm: cdi-vm-dv-wind
    flavor.template.cnv.io/medium: "true"
    os.template.cnv.io/win2k12r2: "true"
    template.cnv.ui: openshift_win2k12r2-generic-medium
    vm.cnv.io/template: win2k12r2-generic-medium
    workload.template.cnv.io/generic: "true"
  name: cdi-vm-dv-wind
spec:
  dataVolumeTemplates:
  - metadata:
      name: cdi-dv-wind
    spec:
      pvc:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 27Gi
      source:
          http:
             url: "http://webserver/w2k.qcow2"
    status: {}
  running: false
  template:
    metadata:
      labels:
        kubevirt.io/vm: cdi-vm-dv-wind
    spec:
      domain:
        cpu:
          cores: 1
        devices:
          disks:
          - bootOrder: 1
            disk:
              bus: sata
            name: cdi-datavolume-name-wind
          interfaces:
          - bridge: {}
            model: e1000e
            name: nic0
        machine:
          type: q35
        resources:
          requests:
            memory: 4096M
      terminationGracePeriodSeconds: 0
      volumes:
      - dataVolume:
          name: cdi-dv-wind
        name: cdi-datavolume-name-wind

```

But, it seems if you use GlusterFS as StorageClass takes so much to get imported (tbh I didn't make it, beacuse it fails always after 25-30 minutes), here more log entries: https://pastebin.com/yTbGsD8J

HTH

Given the 'qemu-img info' output above, you will need a PVC of size 23G+ to upload the image.

When uploading a qcow2 file, the qcow2, here's what happens:

1.  The uploaded qcow2 file is saved to a temp dir on the PVC
2.  'qemu-img convert' creates a raw file from the qcom2 file
3.  The temp dir is deleted

In the datavolume example you include, we are doing an import, not an upload.  Import works differently form upload.  When importing a qcow2 file from http, we can invoke 'qemu-img convert' directly on the URL.  This keeps us from having to first download the file.  And allows us to be more space efficient.

Unless you can't upload the referenced qcow2 file to a 23G+ PVC, I'd say things are working as expected.

We implemented scratch space which will create a temporary storage space the same size of the target space and save the upload there, then convert/transfer to the target. It has size detection which will let you know if there is enough space.

Verified using hco 2.0.0-30

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:1850