Bug 803344 - qemu-img convert doesn't print errno strings on I/O errors
qemu-img convert doesn't print errno strings on I/O errors
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.2
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Kevin Wolf
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-14 09:48 EDT by Jakub Libosvar
Modified: 2013-01-09 19:47 EST (History)
10 users (show)

See Also:
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 07:45:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0746 normal SHIPPED_LIVE qemu-kvm bug fix and enhancement update 2012-06-19 15:31:48 EDT

  None (edit)
Description Jakub Libosvar 2012-03-14 09:48:56 EDT
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.
Comment 3 Kevin Wolf 2012-03-15 04:46:03 EDT
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)
Comment 4 juzhang 2012-03-15 04:56:58 EDT
Same question like comment3
QE did some testing,this issue only can reproduced under source image size(real size) > destination size(block image).
Comment 5 Jakub Libosvar 2012-03-15 07:06:04 EDT
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
Comment 6 Jakub Libosvar 2012-03-15 07:11:50 EDT
Indeed, amount from comment 5 was obtained by using apparent size, du -B 1 shows 2147487744, there is 4KB difference.
Comment 7 Jakub Libosvar 2012-03-15 07:31:04 EDT
Block size on export is 4096 so I suppose this is not internal fragmentation.
Comment 8 Kevin Wolf 2012-03-15 08:16:05 EDT
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?
Comment 9 Jakub Libosvar 2012-03-15 08:22:18 EDT
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.
Comment 10 Kevin Wolf 2012-03-15 08:39:12 EDT
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.
Comment 14 daiwei 2012-03-22 09:26:40 EDT
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.
Comment 16 Michal Novotny 2012-05-04 09:10:01 EDT
    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
Comment 17 errata-xmlrpc 2012-06-20 07:45:09 EDT
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

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