RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2013331 - RFE: qemu-img cannot convert from vdi format
Summary: RFE: qemu-img cannot convert from vdi format
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: qemu-kvm
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: Tingting Mao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-10-12 15:37 UTC by Maya Rashish
Modified: 2022-05-17 12:29 UTC (History)
17 users (show)

Fixed In Version: qemu-kvm-6.1.0-7.el9
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-17 12:24:29 UTC
Type: Feature Request
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat/centos-stream/src qemu-kvm merge_requests 52 0 None None None 2021-11-15 16:48:54 UTC
Red Hat Issue Tracker RHELPLAN-99551 0 None None None 2021-10-12 16:39:54 UTC
Red Hat Product Errata RHBA-2022:2307 0 None None None 2022-05-17 12:24:56 UTC

Description Maya Rashish 2021-10-12 15:37:24 UTC
Description of problem:
Containerized-data-importer is a set of kubernetes containers that prepares images for consumption by KubeVirt, a virtualization tool.
It is currently based on Fedora, and based its supported formats on those allowed by qemu-img in Fedora, one of them being VDI.
(This was requested by an upstream user in https://github.com/kubevirt/containerized-data-importer/pull/1512)
We wanted to change the images to be based on CentOS stream 8 (+advanced-virt), and realized it would no longer allow us to convert from VDI to raw, as --disable-vdi is passed to qemu during the build.

It would be nice if it was a supported format.

Version-Release number of selected component (if applicable):
CentOS stream 8, qemu-img 5.2.0-16

How reproducible:
100%

Steps to Reproduce:
touch fake.vdi; qemu-img convert -f vdi -O raw fake.vdi out.img

Actual results:
qemu-img: Could not open 'fake.vdi': Unknown driver 'vdi'
(error that vdi is not a supported format)

Expected results:
Expected error about invalid VDI image, e.g.
qemu-img: Could not open 'fake.vdi': Image not in VDI format (bad signature 00000000)
(error that it isn't a valid vdi image)

Comment 16 Maya Rashish 2021-11-15 04:52:42 UTC
I'm happy to test out package changes.

Comment 17 Kevin Wolf 2021-11-15 16:40:17 UTC
I submitted a scratch build here: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=41305391

The x86_64 build seems to still be waiting, though, so if this is what you'd want to use for testing, it might still take a while until it is available.

Comment 19 Jeff Squyres 2021-11-15 18:55:35 UTC
Does the metadata attached to this bug mean that the fix won't be applied until CentOS stream 9?  And if so, does that correspond to RHEL 9?

Comment 20 Klaus Heinrich Kiwi 2021-11-15 19:03:21 UTC
(In reply to Jeff Squyres from comment #19)
> Does the metadata attached to this bug mean that the fix won't be applied
> until CentOS stream 9?  And if so, does that correspond to RHEL 9?

The relevant field is the "Internal Target Release" that I'm honestly not sure if it's publicly visible. It is set to 9.0.0, meaning the expectation is to have it on RHEL9-GA

Comment 22 Maya Rashish 2021-11-21 10:25:43 UTC
qemu-kvm-6.1.0-7.el9 looks good to me, thanks!

Comment 23 Yanan Fu 2021-11-24 02:28:18 UTC
QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.

Comment 27 Tingting Mao 2021-11-24 06:19:45 UTC
Hi Kevin,

I have tried to verify this bug with qemu-iotests as below. Could you please help to check the results?

Thanks.


Tested with:
qemu-kvm-6.1.0-7.el9
kernel-5.14.0-15.el9.x86_64


Steps:
1. Find the qemu-iotests directory 
# cd /usr/lib64/qemu-kvm/tests-src/tests/qemu-iotests

2. Prepare the test env
# export QEMU_PROG=/usr/libexec/qemu-kvm 
# export QEMU_IMG_PROG=/usr/bin/qemu-img 
# export QEMU_IO_PROG=/usr/bin/qemu-io 
# export QEMU_NBD_PROG=/usr/bin/qemu-nbd 
# export QSD_PROG=/usr/bin/qemu-storage-daemon

3. Execute the iotests of vdi
# ./check -vdi
......
......
Not run: 007 013 014 015 017 018 019 020 022 023 024 025 026 027 028 029 030 031 034 035 036 037 038 039 040 041 042 043 044 045 046 047 048 049 050 051 053 054 055 056 057 058 059 060 061 062 063 064 065 066 068 069 070 071 073 074 075 076 077 078 079 080 081 082 083 085 086 087 088 089 090 091 092 093 094 095 096 097 098 099 101 102 103 105 106 107 108 109 110 111 112 113 114 115 116 117 119 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 141 142 144 146 147 148 149 150 151 152 153 154 155 156 158 160 161 162 163 165 171 172 173 175 176 177 178 179 181 182 183 185 186 187 188 189 190 191 194 195 196 198 200 201 202 203 204 205 206 207 209 210 212 213 214 216 217 218 219 220 221 222 223 224 225 228 229 231 232 233 234 235 237 239 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 270 271 272 273 274 279 280 281 282 283 284 286 287 288 289 290 292 293 294 295 296 297 298 299 301 302 303 304 305 310 312 313 migrate-bitmaps-postcopy-test migrate-bitmaps-test mirror-top-perms nbd-qemu-allocation parallels-read-bitmap qemu-img-bitmaps qsd-jobs remove-bitmap-from-backing
Failures: 118 120 211 236 307 308 fuse-allow-other
Failed 7 of 42 iotests

Comment 30 Hanna Czenczek 2021-11-25 07:48:40 UTC
(In reply to Tingting Mao from comment #27)
> Failures: 118 120 211 236 307 308 fuse-allow-other
> Failed 7 of 42 iotests

Hi, looking it (without knowing your failure diffs), the problem to me appears to be that the VDI driver is not in our --block-drv-rw-whitelist, but only in --block-drv-ro-whitelist (intentionally so, because we didn’t want to enable it fully in the system emulator).  Now for running the iotests, that’s a problem, because if you ask for a format to be tested (VDI in this case), then all tests will assume it’s fully supported by the system emulator.

Therefore, because our configuration prohibits the system emulator (qemu-kvm) from opening VDI images R/W, basically all iotests that run this system emulator are bound to fail – if there’s an error message, it’ll be something like “Block node is read-only”, or “Driver 'vdi' can only be used for read-only devices”, or “Driver is not whitelisted”.  And that’s basically expected, because as said above, if you run the iotests for a given format, all tests will assume that that format is fully supported (which it isn’t here).

Hanna

Comment 31 Tingting Mao 2021-11-26 07:35:26 UTC
Thanks for Hanna's info.

Checked all the failed cases, there are error messages like “Block node is read-only”, or “Driver 'vdi' can only be used for read-only devices”, or “Driver is not whitelisted”. 

And also tried the basic scenarios of the bug, all passed. So set this bug as verified.


Tested with:
qemu-kvm-6.1.0-7.el9
kernel-5.14.0-15.el9.x86_64


Steps:
1. Create a vdi image.
# qemu-img create -f vdi test.vdi 1G
Formatting 'test.vdi', fmt=vdi size=1073741824 static=off

2. Create a raw image and convert it to vdi image
# qemu-img create -f raw test.img 1G
# qemu-io -c 'write -P 1 0 512M' -f raw test.img
# qemu-img convert -f raw -O vdi test.img target.vdi -p
    (100.00/100%)

3. Convert a vdi image to raw image
# qemu-img convert -f vdi -O raw target.vdi target.raw -p
    (100.00/100%)

Comment 33 errata-xmlrpc 2022-05-17 12:24:29 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 (new packages: qemu-kvm), 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-2022:2307


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