Bug 728992

Summary: Libvirt broken large file support [6.2]
Product: Red Hat Enterprise Linux 6 Reporter: Eric Blake <eblake>
Component: libvirtAssignee: Eric Blake <eblake>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 6.2CC: amyagi, crobinso, dallan, dyuan, eblake, laurent_defert, mzhan, rwu, veillard, xen-maint, yupzhang
Target Milestone: rcKeywords: Regression
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-0.9.4-3.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 728772 Environment:
Last Closed: 2011-12-06 11:23:50 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:
Bug Depends On: 728772, 729194    
Bug Blocks:    

Description Eric Blake 2011-08-08 15:05:11 UTC 
Cloning to RHEL 6.2.  Laurent's one-liner configure.ac patch is more appropriate than backporting a .gnulib submodule update.

+++ This bug was initially created as a clone of Bug #728772 +++

Created attachment 517037 [details]
Patch to bring back large file support

Description of problem:
Using the latest git version (as of Aug. 7 2011), libvirt cannot open VM image whose size is superior to 2Go (on my system at least). It appears the regression has been introduced in commit 70e05fa6d033eeebaf7e072233b45d334d6139d8.
The attached patch partly reverts this commit to fix large file support (not sure wether it's the right way to fix it, since it's supposed to be handled by the gnulib).

Version-Release number of selected component (if applicable):
Since 0.9.4

How reproducible:
Always

Steps to Reproduce:
1. Start a VM whose size is > 2Go.

Actual results:
Get this error:
12:57:21.637: 26033: error : virDomainDiskDefForeachPath:11380 : unable to open disk path /home/virtkvm/storage/VM1.img: Value too large for defined data type

--- Additional comment from veillard on 2011-08-08 01:27:09 MDT ---

This is likely to be a portability issue, what is the system you are using
and can you post the relevant part of the config.log configure ouput,

 thanks,

Daniel

--- Additional comment from eblake on 2011-08-08 08:44:58 MDT ---

Gnulib already invokes AC_SYS_LARGEFILE; re-adding it to configure.ac shouldn't be changing anything.

--- Additional comment from eblake on 2011-08-08 08:51:28 MDT ---

Oh - I see - this is a nasty bug in gnulib:
http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=7c185762
introduced modules/largefile, but mistakenly has 'configure.ac' listed twice, instead of the intended 'configure.ac-early' for AC_REQUIRE([AC_SYS_LARGEFILE]) and 'configure.ac' empty.  As a result, gnulib-tool is no longer invoking AC_SYS_LARGEFILE.

--- Additional comment from eblake on 2011-08-08 08:59:19 MDT ---

Regression introduced in libvirt commit 1c93fbbb, since that is the one that updated the gnulib submodule to include gnulib commit 7c18576.

Laurent's patch is appropriate for applying in backports where a full gnulib update is not appropriate.
Comment 1 Eric Blake 2011-08-08 15:06:49 UTC 
Regression introduced in libvirt-0.9.4-0rc2.el6; still present in libvirt-0.9.4-1.el6.
Comment 4 Daniel Veillard 2011-08-09 06:00:32 UTC 
*** Bug 729194 has been marked as a duplicate of this bug. ***
Comment 5 Eric Blake 2011-08-09 15:30:21 UTC 
In POST:
http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-August/msg00317.html

Note that the RHEL solution prefers Laurent's patch, rather than backporting the upstream gnulib update:
commit e6cdb431bdde141585e7f461a2829ad62e99086a
Author: Eric Blake <eblake>
Date:   Mon Aug 8 09:52:03 2011 -0600

    build: fix regression in large file support
    
    * .gnulib: Update to latest, for largefile fix.
Comment 7 yuping zhang 2011-08-16 09:28:45 UTC 
Tested this issue with:

libvirt-0.9.4-4.el6.x86_64
qemu-kvm-0.12.1.2-2.180.el6.x86_64
kernel-2.6.32-178.el6.x86_64

# virsh dumpxml kvm-rhel6.1-i386
...
<disk type='file' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source file='/var/lib/libvirt/images/rhel6u1-32b-raw-kvm.img'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    </disk>
...
# qemu-img info /var/lib/libvirt/images/rhel6u1-32b-raw-kvm.img 
image: /var/lib/libvirt/images/rhel6u1-32b-raw-kvm.img
file format: raw
virtual size: 3.9G (4194304000 bytes)
disk size: 3.9G

# virsh start kvm-rhel6.1-i386
Domain kvm-rhel6.1-i386 started

Hi Eric,

As above,is this issue fixed and can we change status to VERIFIED?

Thanks
Yuping
Comment 8 Eric Blake 2011-08-16 13:07:43 UTC 
(In reply to comment #7)
> Tested this issue with:
> 
> libvirt-0.9.4-4.el6.x86_64
> qemu-kvm-0.12.1.2-2.180.el6.x86_64
> kernel-2.6.32-178.el6.x86_64

Won't work.  To expose the bug, you _have_ to test with libvirt-0.9.4-*.el6.i686 (that is, only 32-bit builds have the bug, so you won't be able to compare failure vs. success unless you are testing a 32-bit build).

Once you have a 32-bit build, the easiest way to test might be to pre-populate a domain log with more than 4GB of space; then do an action that will append to the domain log; if libvirt was compiled with the wrong size for off_t, then libvirt will complain about being unable to open and/or seek to the end of the log file.

Another option that I just tested:
$ gdb path/to/virsh
(gdb) b main
(gdb) r
(gdb) p sizeof(off_t)

which should print 4 on broken builds, 8 otherwise.
Comment 9 yuping zhang 2011-08-17 09:16:08 UTC 
Hi Eric,

I have installed rhel6.2-32bit OS and libvirt-0.9.4-1.el6.i686,but qemu-kvm don't have i686 packages,so I try to install qemu,but in brewweb: https://brewweb.devel.redhat.com/packageinfo?packageID=2609 no qemu el6 package found,I don't know how to create the environment to verify this bug,can you help me?

Thanks
Yuping
Comment 10 Eric Blake 2011-08-17 12:44:59 UTC 
(In reply to comment #9)
> Hi Eric,
> 
> I have installed rhel6.2-32bit OS and libvirt-0.9.4-1.el6.i686,but qemu-kvm
> don't have i686 packages,so I try to install qemu,but in brewweb:
> https://brewweb.devel.redhat.com/packageinfo?packageID=2609 no qemu el6 package
> found,I don't know how to create the environment to verify this bug,can you
> help me?

You don't need qemu to test whether libvirt was compiled with 64-bit off_t.  Have you tried my formula using gdb in comment 8?  That works on the virsh binary, which works on 32-bit platforms even when there is no qemu-kvm.
Comment 11 yuping zhang 2011-08-18 02:25:31 UTC 
Reproduced this issue with :
libvirt-debuginfo-0.9.4-1.el6.i686
libvirt-0.9.4-1.el6.i686
libvirt-python-0.9.4-1.el6.i686
libvirt-client-0.9.4-1.el6.i686

# gdb /usr/bin/virsh 
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-49.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
.....
Reading symbols from /usr/bin/virsh...Reading symbols from /usr/lib/debug/usr/bin/virsh.debug...done.
done.
(gdb) b main
Breakpoint 1 at 0x80676b5: file /usr/include/bits/string3.h, line 85.
(gdb) r
Starting program: /usr/bin/virsh 
[Thread debugging using libthread_db enabled]

Breakpoint 1, main (argc=1, argv=0xbffff6a4) at /usr/include/bits/string3.h:85
85	/usr/include/bits/string3.h: No such file or directory.
	in /usr/include/bits/string3.h
....
(gdb) p sizeof(off_t)
$1 = 4

Tested this issue with:

libvirt-client-0.9.4-4.el6.i686
libvirt-0.9.4-4.el6.i686
libvirt-python-0.9.4-4.el6.i686
libvirt-debuginfo-0.9.4-4.el6.i686

# gdb /usr/bin/virsh 
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-49.el6)
...
Reading symbols from /usr/bin/virsh...Reading symbols from /usr/lib/debug/usr/bin/virsh.debug...done.
done.
(gdb) b main
Breakpoint 1 at 0x80676e5: file /usr/include/bits/string3.h, line 85.
(gdb) r
Starting program: /usr/bin/virsh 
[Thread debugging using libthread_db enabled]

Breakpoint 1, main (argc=1, argv=0xbffff6a4) at /usr/include/bits/string3.h:85
85	/usr/include/bits/string3.h: No such file or directory.
	in /usr/include/bits/string3.h
Missing separate debuginfos, use: debuginfo-install audit-libs-2.1-5.el6.i686 augeas-libs-0.9.0-1.el6.i686 cyrus-sasl-lib-2.1.23-9.el6.i686 device-mapper-libs-1.02.65-1.el6.i686 glibc-2.12-1.35.el6.i686 gnutls-2.8.5-4.el6.i686 keyutils-libs-1.4-2.el6.i686 krb5-libs-1.9-18.el6.i686 libcom_err-1.41.12-9.el6.i686 libcurl-7.19.7-26.el6_1.1.i686 libgcrypt-1.4.5-7.el6.i686 libgpg-error-1.7-4.el6.i686 libidn-1.18-2.el6.i686 libnl-1.1-14.el6.i686 libselinux-2.0.94-5.1.el6.i686 libsepol-2.0.41-4.el6.i686 libssh2-1.2.2-7.el6.i686 libtasn1-2.3-3.el6.i686 libudev-147-2.37.el6.i686 libxml2-2.7.6-2.el6.i686 libxslt-1.1.26-2.el6.i686 ncurses-libs-5.7-3.20090208.el6.i686 netcf-libs-0.1.9-1.el6.i686 nspr-4.8.8-3.el6.i686 nss-3.12.10-2.el6.i686 nss-softokn-freebl-3.12.9-8.el6.i686 nss-util-3.12.10-1.el6.i686 openldap-2.4.23-16.el6.i686 openssl-1.0.0-10.el6_1.4.i686 readline-6.0-3.el6.i686 yajl-1.0.7-3.el6.i686 zlib-1.2.3-27.el6.i686

(gdb) p sizeof(off_t)
$1 = 8

As comment 8 and comment 10,command "(gdb) p sizeof(off_t)" print 4 on broken builds(libvirt-0.9.4-1.el6.686), 8 on fixed build(libvirt-0.9.4-4.el6.i686).
So change the status to VERIFIED
Comment 12 errata-xmlrpc 2011-12-06 11:23:50 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, 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-2011-1513.html