Bug 1032904 - qemu-img can not create libiscsi qcow2_v3 image
qemu-img can not create libiscsi qcow2_v3 image
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.0
x86_64 Linux
high Severity medium
: rc
: ---
Assigned To: Kevin Wolf
Virtualization Bugs
:
: 993515 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-21 03:39 EST by Jun Li
Modified: 2014-06-17 23:42 EDT (History)
9 users (show)

See Also:
Fixed In Version: qemu-kvm-1.5.3-34.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-13 05:31:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jun Li 2013-11-21 03:39:29 EST
Description of problem:
For some iscsi lun using qemu-img to create libiscsi qcow2_v3 img, it will failed.

Version-Release number of selected component (if applicable):
libiscsi-1.9.0-3.el7.x86_64
qemu-kvm-rhev-1.5.3-19.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1.use qemu-kvm to create qcow2_v3 image.
# qemu-img create -f qcow2 -o compat=1.1  iscsi://10.66.6.82:3260/iqn.2013-11.com.example:storage.disk1.juli.xyz/3 3G
2.
3.

Actual results:
# qemu-img create -f qcow2 -o compat=1.1  iscsi://10.66.6.82:3260/iqn.2013-11.com.example:storage.disk1.juli.xyz/3 3G
Formatting 'iscsi://10.66.6.82:3260/iqn.2013-11.com.example:storage.disk1.juli.xyz/3', fmt=qcow2 size=3221225472 compat='1.1' encryption=off cluster_size=65536 lazy_refcounts=off 
qemu-img: iscsi://10.66.6.82:3260/iqn.2013-11.com.example:storage.disk1.juli.xyz/3: Header extension too large


Expected results:
create qcow2_v3 img is successful.

Additional info:
Also test another iscsi lun, it will create successuflly.
# qemu-img create -f qcow2 -o compat=1.1  iscsi://10.66.6.82:3260/iqn.2013-11.com.example:storage.disk1.juli.xyz/4 3G
Formatting 'iscsi://10.66.6.82:3260/iqn.2013-11.com.example:storage.disk1.juli.xyz/4', fmt=qcow2 size=3221225472 compat='1.1' encryption=off cluster_size=65536 lazy_refcounts=off
Comment 2 Kevin Wolf 2013-11-26 05:17:47 EST
Workaround: Zero out the first cluster manually before creating a qcow2 image
on a block device using 'qemu-io -c "write -P 0 0 64k" iscsi://...'

qcow2_create should of course be doing this by itself, thanks for catching the
problem.
Comment 3 Ademar Reis 2013-12-06 07:46:54 EST
*** Bug 993515 has been marked as a duplicate of this bug. ***
Comment 4 Xu Han 2013-12-23 21:52:26 EST
(In reply to Kevin Wolf from comment #2)
> Workaround: Zero out the first cluster manually before creating a qcow2 image
> on a block device using 'qemu-io -c "write -P 0 0 64k" iscsi://...'

Hi Kevin,

I hit this issue as well. But can not resolve this problem by using step above.

# qemu-io -c "write -P 0 0 64k" /dev/sdb6
qemu-io: can't open device /dev/sdb6: Header extension too large
no file open, try 'help open'

This iscsi storage parted as below:
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048  1258293247   629145600    5  Extended
/dev/sdb5            4096    62918655    31457280   83  Linux
/dev/sdb6        62920704   125835263    31457280   83  Linux
/dev/sdb7       125837312   188751871    31457280   83  Linux
/dev/sdb8       188753920   251668479    31457280   83  Linux
/dev/sdb9       251670528   314585087    31457280   83  Linux
/dev/sdb10      314587136   377501695    31457280   83  Linux

Only /dev/sdb5 and /dev/sdb10 could create a qcow2 v3 image.
Comment 5 Xu Han 2013-12-23 21:57:39 EST
(In reply to xuhan from comment #4)
> (In reply to Kevin Wolf from comment #2)
> > Workaround: Zero out the first cluster manually before creating a qcow2 image
> > on a block device using 'qemu-io -c "write -P 0 0 64k" iscsi://...'
> 
> Hi Kevin,
> 
> I hit this issue as well. But can not resolve this problem by using step
> above.
> 
> # qemu-io -c "write -P 0 0 64k" /dev/sdb6
> qemu-io: can't open device /dev/sdb6: Header extension too large
> no file open, try 'help open'
> 
> This iscsi storage parted as below:
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sdb1            2048  1258293247   629145600    5  Extended
> /dev/sdb5            4096    62918655    31457280   83  Linux
> /dev/sdb6        62920704   125835263    31457280   83  Linux
> /dev/sdb7       125837312   188751871    31457280   83  Linux
> /dev/sdb8       188753920   251668479    31457280   83  Linux
> /dev/sdb9       251670528   314585087    31457280   83  Linux
> /dev/sdb10      314587136   377501695    31457280   83  Linux
> 
> Only /dev/sdb5 and /dev/sdb10 could create a qcow2 v3 image.

Disk /dev/sdb: 1610.6 GB, 1610612736000 bytes, 3145728000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x064cba89
Comment 6 Kevin Wolf 2014-01-07 06:38:27 EST
(In reply to xuhan from comment #4)
> (In reply to Kevin Wolf from comment #2)
> > Workaround: Zero out the first cluster manually before creating a qcow2 image
> > on a block device using 'qemu-io -c "write -P 0 0 64k" iscsi://...'
> 
> Hi Kevin,
> 
> I hit this issue as well. But can not resolve this problem by using step
> above.
> 
> # qemu-io -c "write -P 0 0 64k" /dev/sdb6
> qemu-io: can't open device /dev/sdb6: Header extension too large
> no file open, try 'help open'

Oh, yes, of course, this only works as long as qemu-io still detects it as a
raw image. Unfortunately, qemu-io doesn't seem to have an options to force the
file format. You can probably fix it outside qemu then and use dd to zero out
the first 64k after getting a host block device for the iscsi volume.

Anyway, this has been fixed by upstream commit f8413b3c and I'm planning to
backport the fix today.
Comment 7 Miroslav Rezanina 2014-01-08 07:44:07 EST
Fix included in qemu-kvm-1.5.3-34.el7
Comment 9 Jun Li 2014-01-27 23:38:00 EST
Reproduce this issue:
Version-Release number of selected component (if applicable):
qemu-kvm-1.5.3-33.el7.x86_64
---
Steps as comment #0,
# qemu-img create -f qcow2 -o compat=1.1 iscsi://10.66.4.204:3260/iqn.2014-01.com.example:juli/3 3G
Formatting 'iscsi://10.66.4.204:3260/iqn.2014-01.com.example:juli/3', fmt=qcow2 size=3221225472 compat='1.1' encryption=off cluster_size=65536 lazy_refcounts=off 
---
Can not reproduce this issue.
---
Verify:
Version-Release number of selected component (if applicable):
qemu-kvm-1.5.3-39.el7.x86_64
3.10.0-65.el7.x86_64
---
Steps as comment #0,
qemu-img create -f qcow2 -o compat=1.1 iscsi://10.66.4.204:3260/iqn.2014-01.com.example:juli/3 3G
Formatting 'iscsi://10.66.4.204:3260/iqn.2014-01.com.example:juli/3', fmt=qcow2 size=3221225472 compat='1.1' encryption=off cluster_size=65536 lazy_refcounts=off
----
Based on above test, no hit this issue with qemu-kvm-1.5.3-39.el7.x86_64.
Comment 11 Ludek Smid 2014-06-13 05:31:06 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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