Description of problem: Gnome Boxes fails to set up a qemu. Tested on Archlinux and Ubuntu Natty ISOs. Version-Release number of selected component (if applicable): gnome-boxes3.9.3-2.fc20 How reproducible: Always Steps to Reproduce: 1.Run Gnome Boxes 2.Select ISO of desired OS Actual results: 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 Expected results: Successful creation of Box
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.