Took me times to figure out what was going on, the wiki speak about qemu-kvm and i don't get it. Finally, using --jobs=1 i saw the culprit : make[1]: Entering directory '/var/tmp/portage/app-emulation/qemu-1.6.1/work/qemu-1.6.1/softmmu-build/i386-softmmu' install -m 755 qemu-system-i386 "/var/tmp/portage/app-emulation/qemu-1.6.1/image//usr/bin" make[1]: Leaving directory '/var/tmp/portage/app-emulation/qemu-1.6.1/work/qemu-1.6.1/softmmu-build/i386-softmmu' * You disabled QEMU_SOFTMMU_TARGETS=x86_64, this disables install * of the /usr/bin/qemu-kvm script. * python2_7: running qemu_python_install >>> Completed installing qemu-1.6.1 into /var/tmp/portage/app-emulation/qemu-1.6.1/image/ It should be note that "not enabling" something is not really the same as "disabling it" ;) So no i didn't enable x86_64 because i don't need it and think i cannot use it anyway (don't know but i suppose my x86 host cannot host a 64bits one). So no qemu-kvm because i don't enable x86-64 on a x86 arch ? If anyone can provide an explain to this (and it would be better to elog this as postint warn like other messages). Thank you. Reproducible: Always Expected Results: Have qemu-kvm app-emulation/qemu-1.6.1 was built with the following: USE="aio alsa caps curl filecaps gtk jpeg ncurses opengl png python sdl seccomp threads usb uuid vhost-net vnc -accessibility -bluetooth -debug -fdt -glusterfs -iscsi -mixemu -pulseaudio -rbd -sasl (-selinux) -smartcard (-spice) -ssh -static -static-softmmu -static-user -systemtap -tci -test -tls -usbredir -vde -virtfs -xattr -xen -xfs" PYTHON_TARGETS="python2_7 -python2_6" QEMU_SOFTMMU_TARGETS="i386 (-alpha) (-arm) -cris -lm32 (-m68k) -microblaze -microblazeel (-mips) -mips64 -mips64el -mipsel -moxie -or32 (-ppc) (-ppc64) -ppcemb -s390x -sh4 -sh4eb (-sparc) -sparc64 -unicore32 -x86_64 -xtensa -xtensaeb" QEMU_USER_TARGETS="(-alpha) (-arm) -armeb -cris -i386 (-m68k) -microblaze -microblazeel (-mips) -mips64 -mips64el -mipsel -mipsn32 -mipsn32el -or32 (-ppc) (-ppc64) -ppc64abi32 -s390x -sh4 -sh4eb (-sparc) -sparc32plus -sparc64 -unicore32 -x86_64" >>> Attempting to run pkg_info() for 'app-emulation/qemu-1.6.1' Using: sys-firmware/ipxe-1.0.0_p20130925 sys-firmware/seabios-1.7.3 USE=binary sys-firmware/vgabios-0.7a
the `qemu-kvm` helper is merely a shortcut: /usr/bin/qemu-system-x86_64 -machine accel=kvm "$@" so run your system binary w/accel=kvm. i wonder if we should just deprecate the qemu-kvm wrapper entirely ? doesn't seem useful, and it'll only get worse as more targets add kvm support (a bunch do already).
I think it would be better : - Kept - Renamed to an explicit qemu-kvm-amd64 - Always install (so others can dig it and see what it is suppose to run) It could also be dup as qemu-kvm-x86 with fine shortcut to i386 in it? The problem is that the wiki refer to that file, and you will only get it for amd64 (user doesn't know it's a shortcut). So maybe update wiki to explicit tell user howto create that file and remove that file from the package, so user won't get the file, but wiki will tell him howto create it.
(In reply to Stéphane Pagnon from comment #2) the point of having `qemu-kvm` is that it's semi-standard. qemu-kvm-$ARCH is not standard, and at that point, is pointless pollution. just add the kvm arg to your invocation and be done. wrt "the wiki", it's (1) a wiki (2) not maintained directly/officially (3) is trivial to fix. so the argument "the wiki says to do X, thus the ebuild must support it" is bogus. the wiki reflects the ebuild, not the other way around.
(In reply to SpanKY from comment #3) > (In reply to Stéphane Pagnon from comment #2) > > the point of having `qemu-kvm` is that it's semi-standard. Must be why wiki refer to it then. So the only problem is that the ebuild silently remove it, leaving user with a semi-standard file not install at all. It would be just better to install it always, and even better made its content using the i386 part, so x86 and x86-64 arch would both have it, and can both run it (yeah i know, x86-64 will be limited to x86 but it will gave something that works to anyone). Just having its content is enough help for majority of users, it didn't took me years to figure out how to change it to met my needs, as soon as i got the file. Or alter the file with some (generic code) if (uname -m == i686) /usr/bin/qemu-system-i386 -machine accel=kvm "$@" else /usr/bin/qemu-system-x86_64 -machine accel=kvm "$@"
(In reply to Stéphane Pagnon from comment #4) pretty sure launching the i386 system on an x86_64 kernel is a bad idea. maintaining a script to try and guess the current kernel $arch and run the corresponding system binary is doable, but a pita. upstream qemu has never installed this. the old qemu-kvm package might have, but the point is to converge. i see no value in keeping it anymore. so unless Doug disagrees, i'll update the 2.0.0/9999 versions to stop installing this completely and add an elog telling people to use accel=kvm arg.
should be all set now in the tree; thanks for the report! Commit message: Drop qemu-kvm wrapper entirely and tell people to use -enable-kvm instead. http://sources.gentoo.org/app-emulation/qemu/qemu-2.0.0.ebuild?r1=1.6&r2=1.7 http://sources.gentoo.org/app-emulation/qemu/qemu-9999.ebuild?r1=1.71&r2=1.72
There's nothing more enjoyable than having remote systems rendered unbootable by software update due to missing a single ELOG message. Thanks!
(In reply to Justus Ranvier from comment #8) > There's nothing more enjoyable than having remote systems rendered > unbootable by software update due to missing a single ELOG message. > > Thanks! Indeed. Any quick way to fix this for machines started by libvirtd?
the ebuild checks for & dies w/a message giving hints as how to tweak your configs ...
(In reply to SpanKY from comment #10) > the ebuild checks for & dies w/a message giving hints as how to tweak your > configs ... Yeah, right. But using libvirtd and changing /usr/bin/qemu-kvm to /usr/bin/qemu-system-x86_64 won't use any hardware acceleration and i didn't find a way to add --enable-kvm or accel=kvm to my libvirt vm configs. Any help would be appreciated.
