qemu's curl driver doesn't support range requests from HTTP/2 servers. These two commits should fix it: commit 69032253c33ae1774233c63cedf36d32242a85fc block/curl: HTTP header field names are case insensitive commit 7788a319399f17476ff1dd43164c869e320820a2 block/curl: HTTP header fields allow whitespace around values
Reproducer: $ qemu-img info https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso On qemu < 5.0 this prints the error: qemu-img: Could not open 'https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso': CURL: Error opening file: Server does not support 'range' (byte ranges). On qemu >= 5.0 it prints normal output, eg: image: https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso file format: raw virtual size: 597 MiB (625999872 bytes) disk size: unavailable We want to backport the fix for this to RHEL 8.2.1.
(In reply to Richard W.M. Jones from comment #2) > Reproducer: > > $ qemu-img info > https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso I thought this reproducer was a good one, but for unclear reasons it doesn't work on RHEL AV 8.3, or at least, not on my machine. It appears to be something to do with TLS, crypto policy etc but I'm not clear what precisely.
(In reply to Richard W.M. Jones from comment #2) > Reproducer: > > $ qemu-img info > https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso > > On qemu < 5.0 this prints the error: > > qemu-img: Could not open > 'https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso': > CURL: Error opening file: Server does not support 'range' (byte ranges). > > On qemu >= 5.0 it prints normal output, eg: > > image: https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso > file format: raw > virtual size: 597 MiB (625999872 bytes) > disk size: unavailable > > We want to backport the fix for this to RHEL 8.2.1. I tried it on rhel820 and rhel830, all work well. Is there any additional configuration? Please help check it. Thanks. rhel820: kernel-4.18.0-165.el8.x86_64 qemu-kvm-4.2.0-19.module+el8.2.0+6296+6b821950 # qemu-img info https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso image: https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso file format: raw virtual size: 597 MiB (625999872 bytes) disk size: unavailable rhel830: kernel-4.18.0-203.el8.x86_64 qemu-kvm-5.0.0-0.module+el8.3.0+6620+5d5e1420 # qemu-img info https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso image: https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso file format: raw virtual size: 597 MiB (625999872 bytes) disk size: unavailable
qa_ack, please?
Tested on rhel8.2.1, hit the following issue. Please help check it and Comment 5. Not sure it can be reproduced by the step. Many thanks. Version: qemu-kvm-4.2.0-22.module+el8.2.1+6758+cb8d64c2 # qemu-img info https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso qemu-img: Could not open 'https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso': Unknown protocol 'https'
Unfortunately this reproducer isn't a good one, and I don't have a good reproducer. The problem is that the server silently falls back to HTTP/1.1 - something to do with available cyphers. So the command appears to succeed, but it tells you nothing about whether the bug is fixed or not. And to further complicate things, the only way to tell what protocol is being used is to recompile qemu-img block/curl.c with verbose debugging enabled. Having said that, the command works fine for me: $ rpm -qf /usr/bin/qemu-img qemu-img-4.2.0-22.module+el8.2.1+6758+cb8d64c2.x86_64 $ qemu-img info https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso image: https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso file format: raw virtual size: 597 MiB (625999872 bytes) disk size: unavailable Can you check if you have the right version of qemu-img installed?
(In reply to Richard W.M. Jones from comment #8) > Unfortunately this reproducer isn't a good one, and I don't have a good > reproducer. > The problem is that the server silently falls back to HTTP/1.1 - something to > do with available cyphers. So the command appears to succeed, but it tells > you > nothing about whether the bug is fixed or not. > > And to further complicate things, the only way to tell what protocol is > being used is to recompile qemu-img block/curl.c with verbose debugging > enabled. > > Having said that, the command works fine for me: > > $ rpm -qf /usr/bin/qemu-img > qemu-img-4.2.0-22.module+el8.2.1+6758+cb8d64c2.x86_64 > $ qemu-img info > https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso > image: https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso > file format: raw > virtual size: 597 MiB (625999872 bytes) > disk size: unavailable > > Can you check if you have the right version of qemu-img installed? Retested, It works well. Many thanks. # qemu-img --version qemu-img version 4.2.0 (qemu-kvm-4.2.0-22.module+el8.2.1+6758+cb8d64c2) # qemu-img info https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso image: https://centos.mirror.liteserver.nl/8/BaseOS/x86_64/os/images/boot.iso file format: raw virtual size: 597 MiB (625999872 bytes) disk size: unavailable Hi zili, Since there isn't a good reproducer, and V2V won't be covered in qemu-kvm test plan. Could you please help verify this bug when it has been fixed? Many thanks.
Verify bug with builds: virt-v2v-1.40.2-23.module+el8.2.1+6797+0db00a40.x86_64 libguestfs-1.40.2-23.module+el8.2.1+6797+0db00a40.x86_64 nbdkit-1.16.2-4.module+el8.2.1+6710+effcb1df.x86_64 qemu-kvm-4.2.0-24.module+el8.2.1+6959+9b840e7c.x86_64 Steps: Scenario 1:Convert a rhel guest from ESXI7.0 to RHV without vddk: # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 -o rhv -os 10.66.144.40:/home/nfs_export -ip /home/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 [ 1.6] Creating an overlay to protect the source from being modified [ 2.1] Opening the overlay [ 24.7] Inspecting the overlay [ 142.7] Checking for sufficient free disk space in the guest [ 142.7] Estimating space required on target for each disk [ 142.7] Converting Red Hat Enterprise Linux 8.2 (Ootpa) to run on KVM virt-v2v: warning: guest tools directory ‘linux/el8’ is missing from the virtio-win directory or ISO. Guest tools are only provided in the RHV Guest Tools ISO, so this can happen if you are using the version of virtio-win which contains just the virtio drivers. In this case only virtio drivers can be installed in the guest, and installation of Guest Tools will be skipped. virt-v2v: This guest has virtio drivers installed. [1395.2] Mapping filesystem data to avoid copying unused and blank areas [1397.5] Closing the overlay [1397.8] Assigning disks to buses [1397.8] Checking if the guest needs BIOS or UEFI to boot [1397.8] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export [1398.4] Copying disk 1/1 to /tmp/v2v.XbPNhl/5792ab14-7746-4340-a27d-845dc12b8db9/images/d2b68c18-08b6-46a8-8cde-d95ff2cdc5d0/baa7869f-7020-40ad-892a-ac3cbaefb1c0 (raw) (100.00/100%) [2379.0] Creating output metadata [2379.2] Finishing off Result 1:virt-v2v can convert guest successfully,and guest can pass normal checkpoints. Scenario 2:convert a windows guest from ESXI7.0 to RHV # virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-x86_64 -o rhv -os 10.66.144.40:/home/nfs_export -ip /home/passwd [ 0.0] Opening the source -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-x86_64 [ 1.7] Creating an overlay to protect the source from being modified [ 2.1] Opening the overlay [ 17.0] Inspecting the overlay [ 135.5] Checking for sufficient free disk space in the guest [ 135.5] Estimating space required on target for each disk [ 135.5] Converting Windows Server 2019 Standard to run on KVM virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing. Firstboot scripts may conflict with PnP. virt-v2v: warning: QEMU Guest Agent MSI not found on tools ISO/directory. You may want to install the guest agent manually after conversion. virt-v2v: warning: there are no virtio drivers available for this version of Windows (10.0 x86_64 Server). virt-v2v looks for drivers in /usr/share/virtio-win The guest will be configured to use slower emulated devices. virt-v2v: This guest does not have virtio drivers installed. [ 149.1] Mapping filesystem data to avoid copying unused and blank areas [ 150.2] Closing the overlay [ 150.5] Assigning disks to buses [ 150.5] Checking if the guest needs BIOS or UEFI to boot [ 150.5] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export [ 150.8] Copying disk 1/1 to /tmp/v2v.QiIxGP/5792ab14-7746-4340-a27d-845dc12b8db9/images/bf1deb79-387c-45ab-91a4-5a2f6f48dc7e/2cce187b-3a19-4398-ae54-474cbe2d3834 (raw) (100.00/100%) [2098.5] Creating output metadata [2098.7] Finishing off Result 2:virt-v2v can convert guest successfully,and guest can pass normal checkpoints. Scenario 3:Use non-admin user to convert a rhel guest from ESXI7.0 to RHV without vddk: # virt-v2v -ic vpx://vsphere.local%5clz.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 -o rhv -os 10.66.144.40:/home/nfs_export -ip /home/passwd [ 0.0] Opening the source -i libvirt -ic vpx://vsphere.local%5clz.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64 [ 1.7] Creating an overlay to protect the source from being modified [ 2.2] Opening the overlay [ 25.0] Inspecting the overlay [ 143.4] Checking for sufficient free disk space in the guest [ 143.4] Estimating space required on target for each disk [ 143.4] Converting Red Hat Enterprise Linux 8.2 (Ootpa) to run on KVM virt-v2v: warning: guest tools directory ‘linux/el8’ is missing from the virtio-win directory or ISO. Guest tools are only provided in the RHV Guest Tools ISO, so this can happen if you are using the version of virtio-win which contains just the virtio drivers. In this case only virtio drivers can be installed in the guest, and installation of Guest Tools will be skipped. virt-v2v: This guest has virtio drivers installed. [1395.9] Mapping filesystem data to avoid copying unused and blank areas [1398.1] Closing the overlay [1398.4] Assigning disks to buses [1398.4] Checking if the guest needs BIOS or UEFI to boot [1398.4] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export [1401.0] Copying disk 1/1 to /tmp/v2v.nW2DaR/5792ab14-7746-4340-a27d-845dc12b8db9/images/e5808d3f-2732-47e9-815c-f2d684a1ce8d/5e4054d3-866b-422a-93f8-b9d7fa4e388a (raw) (100.00/100%) [2491.4] Creating output metadata [2491.8] Finishing off Result 3:virt-v2v can convert guest successfully,and guest can pass normal checkpoints. Result:virt-v2v can convert guest from ESXI7.0 successfully without error info,so change bug status from ON_QA to VERIFIED.
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/RHBA-2020:3172