QEMU version 0.14.0 is out. http://download.savannah.gnu.org/releases/qemu/qemu-0.14.0.tar.gz
new kvm contain spice support, this reason reqired more ebuild writing , more paskage testing .... In sample - spice-gtk, libvirt, spice-protocol , etc
How will this affect app-emulation/qemu-kvm-spice?
@Andreis: ahem, spice-gtk isn't required for that since it is client-only. An ebuild for that is in my overlay and will be soon moved to the tree. spice and spice-protocol ebuilds are in the tree and already used for qemu-kvm-9999. They need more keywording, though. And I'll probably catmove them from app-emulation to net-libs. @QEMU-Team: you may want to get some USE flags from qemu-kvm-9999, like "spice" and "rbd" (vhost-net support is kvm-only, or not?) @Johan: qemu-kvm-spice will go away soon (I'll last-rite it even though it's still p.masked)
(In reply to comment #2) > How will this affect app-emulation/qemu-kvm-spice? > app-emulation/qemu-kvm-spice should have never been added to the Portage tree as the entire qemu herd to dev-zero no but he did anyway. Support for the app-emulation/qemu-kvm-spice will be ripped out of the libvirt package once qemu-kvm-0.14 is in the tree and will remain as such.
I should also note that a release of "qemu" is not a release of "qemu-kvm". qemu-kvm is still at 0.14-rc1 and has not seen an official 0.14 release yet.
Created attachment 263605 [details, diff] Patch to fix the addition of pci on nopci targets. http://sourceforge.net/projects/kvm/files/qemu-kvm/0.14.0/ qemu-kvm-0.14.0 is out in the wild :P Some softmmu targets like cris won't build due to and odd quirk in the build system adding pci.o always and making it conflict with pci-stubs.o This is fixed by the attached patch, I'll also submit it to upstream.
(In reply to comment #4) > (In reply to comment #2) > > How will this affect app-emulation/qemu-kvm-spice? > > > > app-emulation/qemu-kvm-spice should have never been added to the Portage tree > as the entire qemu herd to dev-zero no but he did anyway. @Cardoe: The question was simply: "how will this affect qemu-kvm-spice" and I already answered that. Is there any deeper sense in that phrase or do you just blow your stack? > > Support for the app-emulation/qemu-kvm-spice will be ripped out of the libvirt > package once qemu-kvm-0.14 is in the tree and will remain as such. > The only "support" in libvirt is that it allows qemu-kvm-spice to satisfy the dependency for USE=qemu. And what should the following mean? 17:47 <@Cardoe> dev-zero: if you're not going to be in the qemu herd 17:47 <@Cardoe> Please do not touch our packages 17:47 <@Cardoe> You're not in our IRC or anything. 17:48 <@Cardoe> We've said no to qemu-kvm-spice and you added it to the tree anyway To what are you referring exactly? The libvirt DEPEND change? The USE flag change in qemu-kvm-9999.ebuild (for which I had permission from a qemu herd member)? And I guess not informing me about this change: http://sourcestest.gentoo.org/cgi-bin/viewvc.cgi/gentoo/xml/htdocs/proj/en/virtualization/index.xml?r1=1.13&r2=1.14 was just an oversight as the log does not mention anything about removing me but simply states "rework all the virtualization projects into a logical order". Really, what is your problem, Cardoe?
Created attachment 263649 [details, diff] updated patch, see Jan's answer jan kiszka published another patch solving another issue caused by mine: Jan wrote: This unfortunately breaks the build with device assignment enabled. Patch below is required. Generally, I would recommend to avoid using the qemu-kvm tree for anything else than x86 with kvm support. Other use cases ought to work but are rarely tested. Better pick upstream qemu in this case until we reduced the diffs between both trees to a much smaller amount. qemu-kvm-0.15 may become a milestone in this regard.
@klondike, yeah we got the same answer before about upstream only testing and caring about qemu-kvm working with x86/amd64.
spice seems to be broken in qemu-kvm-0.14 since qemu upstream didn't pull bugfixes for it before releasing 0.14. I'm going to attach patches pulled out of patchwork which fixed the issue for me in qemu-kvm-9999.
Created attachment 264025 [details, diff] fix-spice-assert-crash-1.patch
Created attachment 264027 [details, diff] fix-spice-assert-crash-2.patch
there's a unified patch for qemu here: * http://patchwork.ozlabs.org/patch/85081/ resp. * https://patchwork.kernel.org/patch/593551/ (should be the same for qemu and qemu-kvm). Actually, it's quiet interesting that it actually works with qemu (it seems it shouldn't). So, qemu-0.14 needs that patch as well if spice-support gets added to the ebuild.
There's a lot more than just spice problems. Its got a bunch of crashers posted to the devel mailing list that are still being worked on. Once some of the fixes to this start to land, I'll grab those patches up and add a version to the tree. Until then, we shouldn't have qemu-kvm-0.14 in the tree.
It's been over two months. Any update? Since I can't use KVM with app-emulation/qemu and the system-ppc32 emulation (for example) is broken in qemu-kvm-0.13, I have to switch pre-built packages when I switch tasks, which is quite ridicolous. What prevents qemu-kvm-0.14 from being in portage, without the parts that don't work? Or, alternatively, what prevents upstream qemu-0.14 from using KVM with the latest kernel?
Is there any update on the issue? The current situation with qemu, qemu-kvm and qemu-kvm-spice is really confusing for end users - but gentoo really rocks as a small system to start virtual machines from otoh.
0.14.1 was released 2 weeks ago.
(In reply to comment #17) > 0.14.1 was released 2 weeks ago. No it wasn't. You're quoting when qemu 0.14.1 was released, not qemu-kvm.
We'll be skipping 0.14.0 and heading straight to 0.14.1 which will hopefully be bumped in the tree within a few days.
app-emulation-0.14.1 is now in the tree.
