qemu-devel usage

[Juergen Lock]

In article <54F64BBC.4060502 at 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