Bug 1032904
| Summary: | qemu-img can not create libiscsi qcow2_v3 image | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jun Li <juli> |
| Component: | qemu-kvm | Assignee: | Kevin Wolf <kwolf> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.0 | CC: | acathrow, hhuang, juzhang, michen, qiguo, shu, virt-maint, xfu, xuhan |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| 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 09:31:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jun Li
2013-11-21 08:39:29 UTC
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. *** Bug 993515 has been marked as a duplicate of this bug. *** (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. (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 (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. Fix included in qemu-kvm-1.5.3-34.el7 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. 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. |