From owner-freebsd-ports@FreeBSD.ORG Sat Mar 7 18:09:59 2015 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6770767D for ; Sat, 7 Mar 2015 18:09:59 +0000 (UTC) Received: from smtp.kn-bremen.de (gruenbaer.kn-bremen.de [148.251.8.79]) by mx1.freebsd.org (Postfix) with ESMTP id E9F72FAC for ; Sat, 7 Mar 2015 18:09:58 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 066413DE0E87; Sat, 7 Mar 2015 19:09:50 +0100 (CET) Received: from enceladus10.kn-bremen.de (noident@localhost [127.0.0.1]) by enceladus10.kn-bremen.de (8.14.5/8.14.5) with ESMTP id t27I5HOU056582; Sat, 7 Mar 2015 19:05:17 +0100 (CET) (envelope-from nox@enceladus10.kn-bremen.de) Received: (from nox@localhost) by enceladus10.kn-bremen.de (8.14.5/8.14.5/Submit) id t27I5HoV056581; Sat, 7 Mar 2015 19:05:17 +0100 (CET) (envelope-from nox) Date: Sat, 7 Mar 2015 19:05:17 +0100 (CET) From: Juergen Lock Message-Id: <201503071805.t27I5HoV056581@enceladus10.kn-bremen.de> To: scott.wl.furry@gmail.com Subject: Re: qemu-devel usage X-Newsgroups: local.list.freebsd.ports In-Reply-To: <54F64BBC.4060502@gmail.com> Organization: home Cc: freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 18:09:59 -0000 In article <54F64BBC.4060502@gmail.com> you write: >Yeah! I was able to setup qemu-devel(ver 2.20) to use existing qcow2 >images from linux. Sort of... > >The biggest pain I had was getting networking to play along. No matter >what settings, modules or otherwise I tried, I could not get the VM >image to use an existing tap interface accepting DHCP from my server. >Turns out the problem was rather undocumented and buried in installed files. > >The files "/usr/local/etc/qemu-if[up|down]" are two lines each. One is >the sh-bang, the other is a line saying "exec true". And this is the >default installed to the system by the port files. The >qemu-ifXXXX.sample files are not much help either as they contain the >exact same content. Link(1)(see refs below) makes no mention of the >default ifup|down script files. Would it be prudent to setup an >/etc/qemu folder so users can place their local networking scripts >there? Is this the correct location? > You can just edit the /usr/local/etc/qemu-if{up,down} in place, they won't be overwritten on qemu port updates if they differ from their .sample counterparts. >FWIW, my solution was to "edit" the scripts. I replaced the "exec true" >in qemu-ifup with "/sbin/ifconfig bridge0 addm ${1} up" to add a tap to >the existing bridge. In the qemu-ifdown, "exec true" was replaced with >"/sbin/ifconfig ${1} destroy". End result - still need root access to >start VM because of networking. > Yes. :( >I didn't have to go to this extreme when I setup qemu networking on a >linux box. However, new OS. :) > > From my original setup files for qemu, I had used the -enable-kvm and >-cpu host flags (see 2 below). Qemu on BSD just didn't want to accept >"host" as a cpu option. The reference did point out how the flag worked, >something I didn't realize. However, it would be really good to have the >"host" flag to pass along the cpu accelerators to the VM without having >to call them individually. Is anyone working on this? > >And on the topic of cpu's, when I get a listing of the supported cpu's ( >qemu -cpu help ), it seems the listing is abbreviated. There is no >mention of later cpu types (either intel or AMD). Am I missing something? > >Ref (3) talks about using kqemu-kmod. A kqemu-kmod-devel exists in the >ports tree. However, I saw a reference on the KVM page (which I can't >find again :< ) talking about how kvm aspects including kqemu were being >absorbed into qemu mainline. Can someone clarify, please. Are there any >kernel modules required for normal usage? Documentation seems a little >sparse for FreeBSD/qemu hosts. Is the -enable-kvm flag mentioned earlier >still required here? > A little bit of history: qemu started as jit-only (software emulation), then came kqemu, then kqemu was replaced by kvm. However, the FreeBSD kvm kernel bits port was never finished so recent qemu versions (qemu-devel, qemu-sbruno) are stuck with jit again which means for x86-on-x86 virtualization you're better off with bhyve or vbox, they're simply faster, https://www.freebsd.org/doc/en/books/handbook/virtualization.html https://wiki.freebsd.org/bhyve https://wiki.freebsd.org/VirtualBox The main use of the qemu ports on FreeBSD is for testing/emulating other than the host arch, including the wip qemu-user-static for running individual other-arch executables like for building armv6/mips/mips64 packages on x86 using poudriere, see the wiki, https://wiki.freebsd.org/QemuUserModeHowTo and sbruno's blog, http://blog.ignoranthack.me/?p=212 And if you really want to use kqemu still there's the old version emulators/qemu that you then need to build from ports with the kqemu knob enabled and pass -enable-kqemu or -kernel-kqemu at runtime, but kqemu never was really stable anyway especially for 64bit guests. >Appreciated!!! > >(1) https://wiki.freebsd.org/qemu >(2) http://www.linux-kvm.org/page/Tuning_KVM >(3) http://www.linux-kvm.org/page/BSD > Hope that explains the state of things a bit... Juergen