==== FreeBSD host notes: - needs to run as root in order to use /dev/tap* networking (why?) (actually RELENG_6 and above now has a sysctl net.link.tap.user_open to allow users to use it too. don't forget to adjust device node permissions in /etc/devfs.rules.) - slirp (usermode networking) is fixed now in cvs, on FreeSBIE 1.0 guests you still have to manually do: echo nameserver 10.0.2.3 >/etc/resolv.conf but i've been told that that's normal. (fixed on FreeSBIE 1.1.) and you have to wait a bit for dhclient to do its thing; traffic to address 10.0.2.2 is routed to 127.1 on the host. - expect timer problems when guest kernel HZ is > hosts, for example time sleep 1 takes 49 seconds and booting sleeps for minutes at the acd0 probe with a FreeSBIE 1.0 guest, thats because its kernel is built with HZ=5000, and FreeBSD's default is 100... (no longer a problem with FreeSBIE 1.1.) The linux 2.6 kernel uses 1000 by default btw (changed to 250 recently). Enabling /dev/rtc doesn't seem to help either (not included since it needs a patch to emulators/rtc.) - using physical media doesn't work on 4.x hosts (missing DIOCGMEDIASIZE ioctl.) - the -smb option (smb-export local dir to guest) needs the net/samba3 port/package installed in addition to qemu. - RELENG_6 and up guests often crash while accessing the emulated cdrom (see kern/84102, http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/84102), using a kernel without PREEMPTION has been reported to fix this problem. (or do an ftp install instead of installing from the emulated cdrom, and then make a new kernel.) [fixed since 6.0-R.] - 6.0-RC1 was released with an ed driver that doesn't like qemu's emulated RTL8029 nic, this has been fixed in the meantime but if for some reason you need to use that version as a guest you can temporarily add the patch in this message: http://docs.freebsd.org/cgi/mid.cgi?200510131428.21211.jkim (not included in the port since the used VIA VT86C926 PCI ID does not really match the emulated nic exactly, it just `happens' to work with 6.0-RC1's driver.) - if you want to use usb devices connected to the host in the guest (usb_add host:... monitor command) you need to make sure the host isn't claiming them, e.g. for umass devices (like memory sticks or external harddrives) make sure umass isn't in the kernel (you can then still load it as a kld when needed), also unless you are running qemu as root you then need to fix permissions for /dev/ugen* device nodes: if you are on 5.x or later (devfs) put a rule in /etc/devfs.rules, activate it in /etc/rc.conf and run /etc/rc.d/devfs restart. example devfs.rules: [ugen_ruleset=20] add path 'ugen*' mode 660 group operator corresponding rc.conf line: devfs_system_ruleset="ugen_ruleset" - still usb: since the hub is no longer attached to the uchi controller and the wakeup mechanism, resume interrupt is not implemented yet linux guests will suspend the bus, i.e. they wont see devices usb_add'ed after its (linux') uhci module got loaded. workaround: either add devices before linux loads the module or rmmod and modprobe it afterwards. - to avoid panics or non-working re(4) nics with FreeBSD guests if you use qemu -net nic,model=rtl8139 -net user or tap ... enable the emulated rtl8139 timer by building the port with RTL8139_TIMER enabled. (the rtl8139c+ that model=rtl8139 emulates needs less cpu than qemu's default ne2k nic which is driven by ed(4), it has not been made default only because it may not work with all guests yet. btw qemu now also can emulate a few intel eepro100 and e1000 nics which seem to be a tad more efficient even, and at least i82557b and e1000 work without tweaks for FreeBSD guests - driven by fxp(4) and em(4) repectively - and Linux guests too.) - if you get repeated `atapi_poll called!' console messages with FreeBSD guests or other weird cdrom problems then thats probably because the guest has atapicam loaded, which for reasons still to be determined has problems with qemu's now by default enabled cdrom dma. You can build the port with CDROM_DMA disabled to disable it. - if you build qemu wihout SDL and then get crashes running it try passing it -nographic. This should probably be default in that case... - slirp (-net user) seems to be unstable on amd64 hosts, if this affects you please use tuntap for now. Scott Robbins posted a tap howto for -current here: http://forums.bsdnexus.com/viewtopic.php?id=1563 and one for 6 and 5(?) is here: http://acidos.bandwidth-junkies.net/index.php?Sect=qemu - perhaps it should be noted that if you want to use qemu with -m 512 or larger on i386 hosts you need to increase the kern.maxdsiz tunable in loader.conf(5) since the default is 512 MB, and qemu needs memory for itself also. - if you use kqemu make sure your kqemu.ko is always in sync with your kernel (like with any kld installed outside of base), i.e. rebuild its port whenever you update the kernel - especially if you are switching branches or are following a -stable or even -current branch! - you can enable autoloading of kqemu (and aio) at boot by adding a line kqemu_enable=YES to /etc/rc.conf - kqemu liked to panic the host on amd64 SMP until before 1.3.0.p11_6 (revision 1.25 of /usr/ports/emulators/kqemu-kmod/Makefile), so if your host is such you might want to make sure your kqemu-kmod port is new enough. (and don't forget to reload it...) - qemu's network boot roms (-boot n) have a bug when bootfiles sizes are a multiple of blksize, if this affects you (like with FreeBSD's /boot/pxeboot) you can do like cp /boot/pxeboot pxeboot-qemu && chmod +w pxeboot-qemu && echo >>pxeboot-qemu and then use pxeboot-qemu. Actually you need latest -stable or -current btx code (from after 7.0 was released) because of the real mode boot problem, so use at least pxeboot from there. And I just did that for the pxeboot extracted out of ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200805/7.0-STABLE-200805-i386-bootonly.iso and placed it here: http://people.freebsd.org/~nox/qemu/pxeboot-qemu - if you use slirp (usernet, the default) and want to mount nfs into the guest and you are not running qemu as root, then mountd(8) on the exporting box needs to be run with -n in order to accept requests from ports >= 1024. - unfortunately there can still be guests that don't run correctly with kqemu and -kernel-kqemu especially on amd64 - not much you can do about that other than help debugging (k)qemu... (well or falling back to unaccellerated qemu/leaving out -kernel-kqemu if its that what's causing the problems. note however that kqemu now can also be used with the 32 bit qemu even on amd64 hosts as of the 20080620 update.) - the new (optional) pcap code cannot talk to the host on 6.x because the necessary bpf feature (BIOCFEEDBACK) hasn't (yet?) been merged there. - qemu now uses aio at least for ide dma, so if you get `Invalid system call' crashes that is because aio is not (kld)loaded. - The default configuration location (qemu-ifup script etc.) has been changed from /etc to PREFIX/etc (usually /usr/local/etc). Move your files accordingly. ====