Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 993423
Summary: | Gnome Boxes fails to setup Box | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | František Zatloukal <fzatlouk> |
Component: | gnome-boxes | Assignee: | Christophe Fergeau <cfergeau> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | berrange, cfergeau, fzatlouk, marcandre.lureau, stephent98, virt-maint, zeenix |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-08-11 20:31:45 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
František Zatloukal
2013-08-05 21:49:54 UTC
What is the output of gnome-boxes --checks? The output is following: • The CPU is capable of virtualization: no • The KVM module is loaded: no • Libvirt KVM guest available: no • Boxes storage pool available: yes • The SELinux context is default: yes (In reply to František Zatloukal from comment #2) > The output is following: > • The CPU is capable of virtualization: no > • The KVM module is loaded: no > • Libvirt KVM guest available: no > • Boxes storage pool available: yes > • The SELinux context is default: yes It seems your cpu does not have VT extensions, is that correct? cat /proc/cpuinfo should tell. This is not a blocker, but means VMs will be slower than they could. I'd also make sure that qemu-img is installed. CPU doesn't support VT, package qemu-img is installed. Btw, this is my CPU: http://ark.intel.com/products/42503/ (2nd generation of netbooks CPUs) (In reply to František Zatloukal from comment #4) > CPU doesn't support VT, package qemu-img is installed. > Btw, this is my CPU: http://ark.intel.com/products/42503/ (2nd generation of > netbooks CPUs) This is hopelessly underpowered for running a VM: Intel® Atom™ Processor N450 (512K Cache, 1.66 GHz) # of Cores 1 # of Threads 2 Clock Speed 1.66 GHz L2 Cache 512 KB Max Memory Size (dependent on memory type) 2 GB Memory Types DDR2-667 Intel® Virtualization Technology (VT-x) No Here are 431 Intel processors that would be a better choice for running a VM: http://ark.intel.com/search/advanced/?s=t&CoreCountMin=2&CoreCountMax=2&VTX=true 1. They support virtualization. 2. They are dual core. I know this CPU is really slow (even for browsing the internet). But, Gnome Boxes should be able to run on these CPUs IMO - they're installed in netbooks so they cannot be replaced for a faster CPUs and many users are using them - they're in the 2nd generation of netbooks. You can find out how slow by running qemu from the command-line: $ qemu-system-x86_64 -m 1024 -cdrom Fedora-Live-Desktop-x86_64-19-1.iso -vga std $ rpm -q qemu-system-x86 qemu-system-x86-1.4.2-5.fc19.x86_64 I've used VirtualBox on that machine - and for example it is good enough to run a server. Anyway, I tried running an iso in qemu and the output is interesting: qemu-system-x86_64: symbol lookup error: qemu-system-x86_64: undefined symbol: rbd_aio_flush After all, it's bug at qemu side IMO, what do you think? Very interesting ... :-) I tested that command before posting it, and that certainly did not happen. AFAICT, there aren't any qemu bugs for that. I would guess a library is missing. If so, qemu may be missing a dependency. So, yes, please open a bug against qemu. Before filing a qemu bug, could you please run: $ sudo yum distro-sync This version of qemu-system-x86_64 does not call rbd_aio_flush: $ rpm -qf /usr/bin/qemu-system-x86_64 qemu-system-x86-1.4.2-5.fc19.x86_64 $ readelf --syms /usr/bin/qemu-system-x86_64 | grep -i aio 11: 0000000000000000 0 FUNC GLOBAL DEFAULT UND io_setup (7) 158: 0000000000000000 0 FUNC GLOBAL DEFAULT UND io_submit (30) 211: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rbd_aio_create_completion 237: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rbd_aio_write 250: 0000000000000000 0 FUNC GLOBAL DEFAULT UND io_cancel (7) 389: 0000000000000000 0 FUNC GLOBAL DEFAULT UND io_destroy (7) 400: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rbd_aio_get_return_value 505: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rbd_aio_release 539: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rbd_aio_discard 576: 0000000000000000 0 FUNC GLOBAL DEFAULT UND io_getevents (7) 749: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rbd_aio_read (In reply to František Zatloukal from comment #0) ... > Version-Release number of selected component (if applicable): > gnome-boxes3.9.3-2.fc20 ... Could you try F19 instead? Debugging VMs is hard enough without the added complications of rawhide ... What version of ceph-libs do you have? The F19 version of ceph-libs does not have rbd_aio_flush: $ rpm -q ceph-libs ceph-libs-0.56.4-1.fc19.x86_64 $ readelf --syms /usr/lib64/librbd.so.1 | grep -i rbd_aio 297: 00000033c9a1b2b0 8 FUNC GLOBAL DEFAULT 11 rbd_aio_discard 319: 00000033c9a1b240 82 FUNC GLOBAL DEFAULT 11 rbd_aio_create_completion 455: 00000033c9a1b2a0 8 FUNC GLOBAL DEFAULT 11 rbd_aio_write 577: 00000033c9a1b2e0 5 FUNC GLOBAL DEFAULT 11 rbd_aio_wait_for_complete 658: 00000033c9a1b2f0 5 FUNC GLOBAL DEFAULT 11 rbd_aio_get_return_value 667: 00000033c9a1b4c0 5 FUNC GLOBAL DEFAULT 11 rbd_aio_release 769: 00000033c9a1b2c0 11 FUNC GLOBAL DEFAULT 11 rbd_aio_read $ rpm -qf /usr/lib64/librbd.so.1 ceph-libs-0.56.4-1.fc19.x86_64 In F19, there is a function rbd_flush, but no function rbd_aio_flush: $ readelf --syms /usr/bin/qemu-system-x86_64 | grep _flush 728: 0000000000000000 0 FUNC GLOBAL DEFAULT UND spice_qxl_flush_surfaces_.2 (8) 808: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rbd_flush $ readelf --syms /usr/lib64/librbd.so.1 | grep _flush 311: 00000033c9a1b2d0 5 FUNC GLOBAL DEFAULT 11 rbd_flush 561: 00000033c9a31fd0 527 FUNC GLOBAL DEFAULT 11 _ZN6librbd6_flushEPNS_8Im $ rpm -qf /usr/bin/qemu-system-x86_64 /usr/lib64/librbd.so.1 qemu-system-x86-1.4.2-5.fc19.x86_64 ceph-libs-0.56.4-1.fc19.x86_64 (In reply to František Zatloukal from comment #0) ... > Terminal output: (gnome-boxes:17395): Boxes-WARNING **: wizard.vala:382: > Failed to create volume: internal error: unable to parse qemu-img output '' > Graphical output: Box setting failed ... This error could be caused by the same inconsistency. Could you try this? $ qemu-img create test-1.img 1G Formatting 'test-1.img', fmt=raw size=1073741824 NB: This will create a file, if it succeeds. qemu switched to rbd_flush with 2:1.0-4: $ sudo yum changelog qemu | less ... * Sun Feb 5 04:00:00 2012 Richard W.M. Jones <rjones> - 2:1.0-4 - Require updated ceph for latest librbd with rbd_flush symbol. ... Could you post version info? $ rpm -q qemu-system-x86 ceph-libs | sort Here is what is in rawhide: $ sudo repoquery --arch=x86_64 --releasever=rawhide qemu-system-x86 ceph-libs ceph-libs-0:0.61.7-2.fc20.x86_64 qemu-system-x86-2:1.5.2-4.fc20.x86_64 I installed qemu in a rawhide nightly image and found the following: qemu-system-x86_64 calls rbd_aio_flush. librbd.so.1 provides rbd_flush and rbd_aio_flush. [liveuser@localhost foo]$ rpm -q qemu-system-x86 ceph-libs | sort ceph-libs-0.61.7-2.fc20.x86_64 qemu-system-x86-1.5.2-4.fc20.x86_64 [liveuser@localhost foo]$ readelf --syms /usr/bin/qemu-system-x86_64 | grep _flush 480: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rbd_aio_flush 997: 0000000000000000 0 FUNC GLOBAL DEFAULT UND spice_qxl_flush_surfaces_.2 (13) 1382: 0000000000fcefa8 4 OBJECT GLOBAL DEFAULT 28 tlb_flush_count [liveuser@localhost foo]$ readelf --syms /usr/lib64/librbd.so.1 | grep _flush 335: 000000000001d4b0 5 FUNC GLOBAL DEFAULT 11 rbd_flush 549: 000000000001d4c0 8 FUNC GLOBAL DEFAULT 11 rbd_aio_flush 593: 0000000000057b10 1139 FUNC GLOBAL DEFAULT 11 _ZN12ObjectCacher17_flush 617: 0000000000034740 432 FUNC GLOBAL DEFAULT 11 _ZN6librbd6_flushEPNS_8Im 643: 0000000000041650 1058 FUNC GLOBAL DEFAULT 11 _ZN6librbd9aio_flushEPNS_ Tested with: $ qemu-kvm -m 4096 -cdrom Fedora-20-Nightly-x86_64-Live-lxde-20130801.12-1.iso -vga std -boot menu=on (In reply to Steve Tyler from comment #10) > Before filing a qemu bug, could you please run: > $ sudo yum distro-sync ... NB: You could hit: Bug 995816 - /bin/dracut-initqueue: line 72: syntax error near unexpected token `fi' (In reply to Steve Tyler from comment #14) > (In reply to František Zatloukal from comment #0) > ... > > Terminal output: (gnome-boxes:17395): Boxes-WARNING **: wizard.vala:382: > > Failed to create volume: internal error: unable to parse qemu-img output '' > > Graphical output: Box setting failed > ... > > This error could be caused by the same inconsistency. Could you try this? > > $ qemu-img create test-1.img 1G > Formatting 'test-1.img', fmt=raw size=1073741824 > > NB: This will create a file, if it succeeds. qemu-img also calls rbd_aio_flush, however qemu-img works as expected with the version of ceph-libs below: $ readelf --syms `which qemu-img` | grep _flush 326: 0000000000000000 0 FUNC GLOBAL DEFAULT UND rbd_aio_flush $ rpm -q qemu-img ceph-libs qemu-img-1.5.2-4.fc20.x86_64 ceph-libs-0.61.7-2.fc20.x86_64 I reproduced the qemu error message in F20 by downgrading ceph-libs[1]. Christophe: The qemu error message is much more informative than the gnome-boxes error message[2]. Is the qemu error message logged somewhere? Could the qemu error message be displayed with the gnome-boxes error message? $ qemu-img create test-1.img 1G qemu-img: symbol lookup error: qemu-img: undefined symbol: rbd_aio_flush $ qemu-system-x86_64 -display none qemu-system-x86_64: symbol lookup error: qemu-system-x86_64: undefined symbol: rbd_aio_flush $ rpm -q qemu-system-x86 qemu-img ceph-libs qemu-system-x86-1.5.2-4.fc20.x86_64 qemu-img-1.5.2-4.fc20.x86_64 ceph-libs-0.56.4-1.fc20.x86_64 [1] Information for build ceph-0.56.4-1.fc20 ID 407544 http://koji.fedoraproject.org/koji/buildinfo?buildID=407544 NB: boost needed to be downgraded too, to satisfy dependencies: Information for build boost-1.53.0-11.fc20 ID 438318 http://koji.fedoraproject.org/koji/buildinfo?buildID=438318 [2] Reported in Comment 0. (In reply to Steve Tyler from comment #19) ... > $ qemu-system-x86_64 -display none ... ^^^^^^^^^^^^^ My test environment is an F20 minimal install, so X is not running ... This is the qemu bug: Bug 995883 - qemu-system-x86_64: symbol lookup error: qemu-system-x86_64: undefined symbol: rbd_aio_flush This is the gnome-boxes bug: gnome-boxes is not reporting the qemu error message.[1] The only reason we discovered the cause of this bug is because František ran qemu-system-x86_64 from the command-line and reported the qemu error message.[2] [1] Comment 0. [2] Comment 8. Ok, I've reported new bug against Gnome Boxes. https://bugzilla.redhat.com/show_bug.cgi?id=995887 Steve reported new bug againts qemu. https://bugzilla.redhat.com/show_bug.cgi?id=995883 So I am closing this bug report as notabug. Thanks, František. BTW, BZ will create internal bug links if you use the syntax "Bug NNNNNN": Bug 995883 Bug 995887 Chapter 5. Using Bugzilla 5.8.1. Autolinkification https://bugzilla.redhat.com/docs/en/html/hintsandtips.html Great, I've never read documentation for BZ :). I hope I'll find time to look at it. Thanks (In reply to Steve Tyler from comment #19) > Christophe: The qemu error message is much more informative than the > gnome-boxes error message[2]. Is the qemu error message logged somewhere? > Could the qemu error message be displayed with the gnome-boxes error message? If it's logged somewhere, this would be somewhere in libvirt logs (maybe in ~/.cache/libvirt/qemu/log/ ). As for showing that in Boxes UI, that's definitely a no as it's only useful if you want to debug what's going on. Since gnome-boxes developers are going to be the first ones to get bug reports for gnome-boxes VM install failures, they might find it worth their while to learn where the log files are and what is in them. (In reply to Steve Tyler from comment #26) > Since gnome-boxes developers are going to be the first ones to get bug > reports for gnome-boxes VM install failures, they might find it worth their > while to learn where the log files are and what is in them. Broken distro is a bit of a corner case, so I don't know for sure what libvirt logs/does not log when it cannot run the qemu binary, nor where it would log exactly. Regular VM logs are stored in the location I mentioned. You could try the reproducer in Comment 19 and look at the log files ... Or are you going to make me do all the work? :-) (In reply to Christophe Fergeau from comment #27) ... > Broken distro is a bit of a corner case, ... qemu does not have an explicit requires for ceph-libs. |