Bug 803344
| Summary: | qemu-img convert doesn't print errno strings on I/O errors | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Jakub Libosvar <jlibosva> |
| Component: | qemu-kvm | Assignee: | Kevin Wolf <kwolf> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.2 | CC: | acathrow, bsarathy, juzhang, kwolf, michen, minovotn, mkenneth, tburke, virt-maint, wdai |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-0.12.1.2-2.253.el6 | Doc Type: | Bug Fix |
| Doc Text: |
No Documentation Needed
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-06-20 11:45:09 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
How large is your source image? First thought was that this might be an out of space error. (Yes, the error reporting of qemu-img in RHEL sucks, we should backport some improvements there to print at least the error string) Same question like comment3 QE did some testing,this issue only can reproduced under source image size(real size) > destination size(block image). It came to my mind too - source image is 2147483648 B and destination LV should have the same size as you can see in description: LV Size 2.00 GiB - that's 2*1024^3 2147483648 Indeed, amount from comment 5 was obtained by using apparent size, du -B 1 shows 2147487744, there is 4KB difference. Block size on export is 4096 so I suppose this is not internal fragmentation. Not quite sure where the additional 4k come from, but if you're putting a qcow2 image on a block device, you're supposed to leave some room for metadata. Is the "block size" that you're talking of the qcow2 cluster size? If no, a difference of 4k makes even less sense. Though if yes, why would one use that? The block size I mentioned was meant for NFS export - the image there is still raw file-based. That was block size of ext4 FS. Maybe the 4K data are irrelevant since this operation fails only if qemu-img convert is used. When in RHEV importing image from file to block without converting to qcow2, it succeeds no matter if there are additional 4kB of data. Oh, the source is raw? Then it's absolutely expected. You need to consider the additional qcow2 metadata in the destination block device size. This is NOTABUG. I'll leave it open anway for backporting better error messages in qemu-img. Reproduced this issue with steps and environment as follows: # uname -r ; rpm -q qemu-kvm 2.6.32-220.el6.x86_64 qemu-kvm-0.12.1.2-2.209.el6.x86_64 1. # lvcreate -n lvtest1 -L 10G wdai 2. # lvcreate -n lvtest2 -L 5G wdai 3. # qemu-img create -f raw /dev/wdai/lvtest1 10G 4. # qemu-img create -f qcow2 /dev/wdai/lvtest2 5G 5. # qemu-img convert -t none -f raw /dev/wdai/lvtest1 -O qcow2 /dev/wdai/lvtest2 qemu-img: error while writing Verified this issue with steps and environment as follows: # uname -r;rpm -q qemu-kvm 2.6.32-251.el6.x86_64 qemu-kvm-0.12.1.2-2.255.el6.x86_64 repeat the above steps ,after step 5 # qemu-img convert -t none -f raw /dev/wdai/lvtest1 -O qcow2 /dev/wdai/lvtest2 qemu-img: error while writing sector 11321344: No space left on device According to Comment 10,this bug had been fixed.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
No Documentation Needed
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. http://rhn.redhat.com/errata/RHBA-2012-0746.html |
Description of problem: In RHEV when one wants to import VM from NFS export domain to iSCSI with converting VM's image from raw to qcow, the conversion fails. I also tried it manually - created LV: /sbin/lvm lvcreate --config " devices { preferred_names = [\"^/dev/mapper/\"] ignore_suspended_devices=1 write_cache_state=0 disable_after_error_count=3 filter = [ \"a%1jlibosva|1jlibosva1|1jlibosva2|1small%\", \"r%.*%\" ] } global { locking_type=1 prioritise_write_locks=1 wait_for_locks=1 } backup { retain_min = 50 retain_days = 0 } " --autobackup n --contiguous n --size 1024m --name fee665ad-65e1-4b3b-a562-a4a941169480 2a8b4e96-e616-4960-9cc8-f381e433571d created image on it using: /usr/bin/qemu-img create -f qcow2 /rhev/data-center/7c66f1fb-6e13-4148-b38b-63f62a3ac7ef/2a8b4e96-e616-4960-9cc8-f381e433571d/images/9a897b7c-b324-45f2-b935-2085b374746b/fee665ad-65e1-4b3b-a562-a4a941169480 10240K then started conversion: /usr/bin/qemu-img convert -t none -f raw /rhev/data-center/7c66f1fb-6e13-4148-b38b-63f62a3ac7ef/dece16d0-39ab-49be-aee6-00b1323bf0f4/images/9a897b7c-b324-45f2-b935-2085b374746b/fee665ad-65e1-4b3b-a562-a4a941169480 -O qcow2 /rhev/data-center/7c66f1fb-6e13-4148-b38b-63f62a3ac7ef/2a8b4e96-e616-4960-9cc8-f381e433571d/images/9a897b7c-b324-45f2-b935-2085b374746b/fee665ad-65e1-4b3b-a562-a4a941169480 Version-Release number of selected component (if applicable): vdsm-4.9-112.8.el6_2.x86_64 qemu-img-0.12.1.2-2.209.el6_2.4.x86_64 How reproducible: Always Steps to Reproduce: 1. In RHEV-M have VM with Preallocated disk on NFS export domain 2. Import this VM with Collapse snapshot checked and select Thin provision for VM's disk Actual results: qemu-img convert command fails Expected results: All succeed Additional info: Can't be reproduced if both (source and destination) images are file-based, must be block device. 'qemu-img convert' command fails after circa 14 seconds and doesn't say much about the error: qemu-img: error while writing LV VG Attr LSize Origin Snap% Move Log Copy% Convert fee665ad-65e1-4b3b-a562-a4a941169480 2a8b4e96-e616-4960-9cc8-f381e433571d -wi-a- 2.00g --- Logical volume --- LV Name /dev/2a8b4e96-e616-4960-9cc8-f381e433571d/fee665ad-65e1-4b3b-a562-a4a941169480 VG Name 2a8b4e96-e616-4960-9cc8-f381e433571d LV UUID yYr7cI-TaeH-DJdG-CCAU-yXQ6-oMUR-D8SpYn LV Write Access read/write LV Status available # open 0 LV Size 2.00 GiB Current LE 16 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:18 Dunno whether qemu-img has some logs. If so, please feel free to ask for them.