Re: [libvirt] [Xen-devel] [libvirt bisection] complete build-armhf-libvirt

Xen's automated testing of libvirt against newer Xen's has found a build issue which it has bisected down to "blockcopy: expose new API in virsh". An instance of the failure can be found in flight 30154: http://lists.xen.org/archives/html/xen-devel/2014-09/msg01063.html links to the logs => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/ click the header of a failing column => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/build-armhf-libvirt/i... click the failing step => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/build-armhf-libvirt/5... virsh-domain.c: In function 'cmdBlockCopy': virsh-domain.c:2003:17: error: comparison is always false due to limited range of data type [-Werror=type-limits] cc1: all warnings being treated as errors It seems to be failing similarly on i386 and I suppose most 32-bit arches. Cheers, Ian. On Mon, 2014-09-08 at 19:30 +0100, xen.org wrote:
branch xen-unstable xen branch xen-unstable job build-armhf-libvirt test libvirt-build
Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try] Tree: libvirt git://libvirt.org/libvirt.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: libvirt git://libvirt.org/libvirt.git Bug introduced: c1d75deea228e7f4a7462aef143e18c456b2a82c Bug not present: 0e8bed817705664764db408c93ba54277ef85157
commit c1d75deea228e7f4a7462aef143e18c456b2a82c Author: Eric Blake <eblake@redhat.com> Date: Fri Aug 29 15:47:28 2014 -0600
blockcopy: expose new API in virsh
Expose the new power of virDomainBlockCopy through virsh (well, all but the finer-grained bandwidth, as that is its own can of worms for a later patch). Continue to use the older API where possible, for maximum compatibility.
The command now requires either --dest (with optional --format and --blockdev), to directly describe the file destination, or --xml, to name a file that contains an XML description such as:
<disk type='network'> <driver type='raw'/> <source protocol='gluster' name='vol1/img'> <host name='red'/> </source> </disk>
[well, it may be a while before the qemu driver is actually patched to act on that particular xml beyond just parsing it, but the virsh interface won't need changing at that time]
Non-zero option parameters are converted into virTypedParameters, and if anything requires the new API, the command can synthesize appropriate XML even if the --dest option was used instead of --xml.
The existing --raw flag remains for back-compat, but the preferred spelling is now --format=raw, since the new API now allows us to specify all formats rather than just a boolean raw to suppress probing.
I hope I did justice in describing the effects of granularity and buf-size on how they get passed through to qemu.
* tools/virsh-domain.c (cmdBlockCopy): Add new options --xml, --granularity, --buf-size, --format. Make --raw an alias for --format=raw. Call new API if new parameters are in use. * tools/virsh.pod (blockcopy): Document new options.
Signed-off-by: Eric Blake <eblake@redhat.com>
For bisection revision-tuple graph see: http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.libvirt.build-arm... Revision IDs in each graph node refer, respectively, to the Trees above.
---------------------------------------- Searching for failure / basis pass: 30154 fail [host=marilith-n4] / 30147 ok. Failure / basis pass flights: 30154 / 30147 Tree: gnulib_libvirt git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try] Tree: libvirt git://libvirt.org/libvirt.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git Latest 2bf7326e10fae4abef536486aa9819331596c379 a48362cdfeb5c948218a2e4bf7cc9354082fc1b6 ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 Basis pass 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d 0eaad0a39c67bdddc56d608ff28fcb490c12b8b3 ea772ca487e219e5d5b82d50da460c4145238038 c33fe5459732fc85c2c279c5e8ed316b8601c58c Generating revisions with ./adhoc-revtuple-generator git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try]#9565c3be73eb6d76b7b42a21d68d2e00a62abb6d-2bf7326e10fae4abef536486aa9819331596c379 git://libvirt.org/libvirt.git#0eaad0a39c67bdddc56d608ff28fcb490c12b8b3-a48362cdfeb5c948218a2e4bf7cc9354082fc1b6 git://xenbits.xen.org/staging/qemu-upstream-unstable.git#ea772ca487e219e5d5b82d50da460c4145238038-ea772ca487e219e5d5b82d50da460c4145238038 git://xenbits.xen.org/xen.git#c33fe5459732fc85c2c279c5e8ed316b8601c58c-93d5f192d4903953baa8c2115534d23140236176 + exec + sh -xe + cd /export/home/osstest/repos/gnulib + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try] + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/libvirt + git remote set-url origin git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/xen + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/gnulib + git remote set-url origin git://drall.uk.xensource.com:9419/git://git.sv.gnu.org/gnulib.git%20[fetch=try] + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/libvirt + git remote set-url origin git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* + exec + sh -xe + cd /export/home/osstest/repos/xen + git remote set-url origin git://drall.uk.xensource.com:9419/git://xenbits.xen.org/xen.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/* Loaded 3001 nodes in revision graph Searching for test results: 30147 pass 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d 0eaad0a39c67bdddc56d608ff28fcb490c12b8b3 ea772ca487e219e5d5b82d50da460c4145238038 c33fe5459732fc85c2c279c5e8ed316b8601c58c 30162 fail 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d c1d75deea228e7f4a7462aef143e18c456b2a82c ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 30159 pass 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d 0eaad0a39c67bdddc56d608ff28fcb490c12b8b3 ea772ca487e219e5d5b82d50da460c4145238038 c33fe5459732fc85c2c279c5e8ed316b8601c58c 30167 pass 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d 0e8bed817705664764db408c93ba54277ef85157 ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 30154 fail 2bf7326e10fae4abef536486aa9819331596c379 a48362cdfeb5c948218a2e4bf7cc9354082fc1b6 ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 30161 pass 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d 0eaad0a39c67bdddc56d608ff28fcb490c12b8b3 ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 30160 fail 2bf7326e10fae4abef536486aa9819331596c379 a48362cdfeb5c948218a2e4bf7cc9354082fc1b6 ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 30163 pass 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d 0e8bed817705664764db408c93ba54277ef85157 ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 30165 pass 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d 0e8bed817705664764db408c93ba54277ef85157 ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 30164 fail 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d c1d75deea228e7f4a7462aef143e18c456b2a82c ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 30166 fail 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d c1d75deea228e7f4a7462aef143e18c456b2a82c ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 30168 fail 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d c1d75deea228e7f4a7462aef143e18c456b2a82c ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 Searching for interesting versions Result found: flight 30147 (pass), for basis pass Result found: flight 30154 (fail), for basis failure Repro found: flight 30159 (pass), for basis pass Repro found: flight 30160 (fail), for basis failure 0 revisions at 9565c3be73eb6d76b7b42a21d68d2e00a62abb6d 0e8bed817705664764db408c93ba54277ef85157 ea772ca487e219e5d5b82d50da460c4145238038 93d5f192d4903953baa8c2115534d23140236176 No revisions left to test, checking graph state. Result found: flight 30163 (pass), for last pass Result found: flight 30164 (fail), for first failure Repro found: flight 30165 (pass), for last pass Repro found: flight 30166 (fail), for first failure Repro found: flight 30167 (pass), for last pass Repro found: flight 30168 (fail), for first failure
*** Found and reproduced problem changeset ***
Bug is in tree: libvirt git://libvirt.org/libvirt.git Bug introduced: c1d75deea228e7f4a7462aef143e18c456b2a82c Bug not present: 0e8bed817705664764db408c93ba54277ef85157
+ exec + sh -xe + cd /export/home/osstest/repos/libvirt + git remote set-url origin git://drall.uk.xensource.com:9419/git://libvirt.org/libvirt.git + git fetch -p origin +refs/heads/*:refs/remotes/origin/*
commit c1d75deea228e7f4a7462aef143e18c456b2a82c Author: Eric Blake <eblake@redhat.com> Date: Fri Aug 29 15:47:28 2014 -0600
blockcopy: expose new API in virsh
Expose the new power of virDomainBlockCopy through virsh (well, all but the finer-grained bandwidth, as that is its own can of worms for a later patch). Continue to use the older API where possible, for maximum compatibility.
The command now requires either --dest (with optional --format and --blockdev), to directly describe the file destination, or --xml, to name a file that contains an XML description such as:
<disk type='network'> <driver type='raw'/> <source protocol='gluster' name='vol1/img'> <host name='red'/> </source> </disk>
[well, it may be a while before the qemu driver is actually patched to act on that particular xml beyond just parsing it, but the virsh interface won't need changing at that time]
Non-zero option parameters are converted into virTypedParameters, and if anything requires the new API, the command can synthesize appropriate XML even if the --dest option was used instead of --xml.
The existing --raw flag remains for back-compat, but the preferred spelling is now --format=raw, since the new API now allows us to specify all formats rather than just a boolean raw to suppress probing.
I hope I did justice in describing the effects of granularity and buf-size on how they get passed through to qemu.
* tools/virsh-domain.c (cmdBlockCopy): Add new options --xml, --granularity, --buf-size, --format. Make --raw an alias for --format=raw. Call new API if new parameters are in use. * tools/virsh.pod (blockcopy): Document new options.
Signed-off-by: Eric Blake <eblake@redhat.com>
Revision graph left in /home/xc_osstest/results/bisect.libvirt.build-armhf-libvirt.libvirt-build.{dot,ps,png,html}. ---------------------------------------- 30168: tolerable ALL FAIL
flight 30168 libvirt real-bisect [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/30168/
Failures :-/ but no regressions.
Tests which did not succeed, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail baseline untested
jobs: build-armhf-libvirt fail
------------------------------------------------------------ sg-report-flight on osstest.cam.xci-test.com logs: /home/xc_osstest/logs images: /home/xc_osstest/images
Logs, config files, etc. are available at http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

On Tue, Sep 09, 2014 at 09:49:47AM +0100, Ian Campbell wrote:
Xen's automated testing of libvirt against newer Xen's has found a build issue which it has bisected down to "blockcopy: expose new API in virsh".
An instance of the failure can be found in flight 30154: http://lists.xen.org/archives/html/xen-devel/2014-09/msg01063.html links to the logs => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/ click the header of a failing column => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/build-armhf-libvirt/i... click the failing step => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/build-armhf-libvirt/5...
virsh-domain.c: In function 'cmdBlockCopy': virsh-domain.c:2003:17: error: comparison is always false due to limited range of data type [-Werror=type-limits] cc1: all warnings being treated as errors
It seems to be failing similarly on i386 and I suppose most 32-bit arches.
Thanks, we've just had a fix for that pushed commit efe5061f5a61d04b1bf21fcac2919a2325f54150 Author: Eric Blake <eblake@redhat.com> Date: Mon Sep 8 08:50:48 2014 -0600 blockjob: avoid 32-bit compilation warning Commit c1d75de caused this warning on 32-bit platforms (fatal when -Werror is enabled): virsh-domain.c: In function 'cmdBlockCopy': virsh-domain.c:2003:17: error: comparison is always false due to limited range of data type [-Werror=type- Forcing the left side of the < to be ull instead of ul shuts up the 32-bit compiler while still protecting 64-bit code from overflow. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

On Tue, 2014-09-09 at 09:54 +0100, Daniel P. Berrange wrote:
On Tue, Sep 09, 2014 at 09:49:47AM +0100, Ian Campbell wrote:
Xen's automated testing of libvirt against newer Xen's has found a build issue which it has bisected down to "blockcopy: expose new API in virsh".
An instance of the failure can be found in flight 30154: http://lists.xen.org/archives/html/xen-devel/2014-09/msg01063.html links to the logs => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/ click the header of a failing column => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/build-armhf-libvirt/i... click the failing step => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/build-armhf-libvirt/5...
virsh-domain.c: In function 'cmdBlockCopy': virsh-domain.c:2003:17: error: comparison is always false due to limited range of data type [-Werror=type-limits] cc1: all warnings being treated as errors
It seems to be failing similarly on i386 and I suppose most 32-bit arches.
Thanks, we've just had a fix for that pushed
Thanks, I grepped libvir-list but must have missed it. Ian.

On 09/09/2014 10:49 AM, Ian Campbell wrote:
Xen's automated testing of libvirt against newer Xen's has found a build issue which it has bisected down to "blockcopy: expose new API in virsh".
An instance of the failure can be found in flight 30154: http://lists.xen.org/archives/html/xen-devel/2014-09/msg01063.html links to the logs => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/ click the header of a failing column => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/build-armhf-libvirt/i... click the failing step => http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/build-armhf-libvirt/5...
virsh-domain.c: In function 'cmdBlockCopy': virsh-domain.c:2003:17: error: comparison is always false due to limited range of data type [-Werror=type-limits] cc1: all warnings being treated as errors
It seems to be failing similarly on i386 and I suppose most 32-bit arches.
Cheers, Ian.
Hi, this should be fixed by commit efe5061f: http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=efe5061f5 Jan
participants (3)
-
Daniel P. Berrange
-
Ian Campbell
-
Ján Tomko