Bug 1676824 - No Bootable Device error for Windows using virtctl image-upload - required PVC size is double image disk
Summary: No Bootable Device error for Windows using virtctl image-upload - required PV...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Storage
Version: 1.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 2.0
Assignee: Michael Henriksen
QA Contact: Natalie Gavrielov
URL:
Whiteboard:
Depends On:
Blocks: 1677392
TreeView+ depends on / blocked
 
Reported: 2019-02-13 10:21 UTC by Vatsal Parekh
Modified: 2019-07-24 20:16 UTC (History)
9 users (show)

Fixed In Version: 1.7.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1677392 (view as bug list)
Environment:
Last Closed: 2019-07-24 20:15:51 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:1850 None None None 2019-07-24 20:15:59 UTC

Description Vatsal Parekh 2019-02-13 10:21:09 UTC
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

Comment 1 Vatsal Parekh 2019-02-13 10:24:33 UTC
(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

Comment 2 Vatsal Parekh 2019-02-13 10:41:47 UTC
Alex, can you help with what more should we debug here?

Comment 3 Michael Henriksen 2019-02-13 19:14:09 UTC
Is 12G the "virtual size" of the qcow2 file or the actual file size?  Can you include the output of "qemu-img info" here?

Comment 4 Michael Henriksen 2019-02-13 19:17:38 UTC
The PVC has to be big enough to support both the physical and virtual sizes of the qcow2 file.

Comment 5 Vatsal Parekh 2019-02-14 09:09:09 UTC
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?

Comment 6 Vatsal Parekh 2019-02-14 09:11:57 UTC
(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?

Comment 7 Juan Manuel Parrilla Madrid 2019-02-14 11:24:23 UTC
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

Comment 8 Michael Henriksen 2019-02-14 13:48:30 UTC
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.

Comment 10 Alexander Wels 2019-04-10 19:27:47 UTC
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.

Comment 11 Natalie Gavrielov 2019-07-02 10:51:35 UTC
Verified using hco 2.0.0-30

Comment 13 errata-xmlrpc 2019-07-24 20:15:51 UTC
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


Note You need to log in before you can comment on or make changes to this bug.