Date: Mon, 24 Aug 2009 09:34:39 +0200 From: martinko <gamato@users.sf.net> To: freebsd-emulation@freebsd.org Subject: Re: Automagic bridged networking with QEMU (tap) Message-ID: <h6tfqf$kb0$1@ger.gmane.org> In-Reply-To: <20090823233419.790325B2E@mail.bitblocks.com> References: <200908232215.n7NMFqkK007704@triton8.kn-bremen.de> <20090823233419.790325B2E@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Bakul Shah wrote:
> I use something simpler that is perhaps less flexible but I
> find my machines don't have enough oomph to handle more than
> 3 or 4 qemu VMs!
>
> /boot/loader.conf
> if_tap_load="YES" # if_bridge will be autoloaded later
>
> /etc/rc.conf
> cloned_interfaces="bridge0" # create these interfaces on bootup
> autobridge_interfaces="bridge0" # autoconfigure these bridges
> autobridge_bridge0="tap* $eth" # $eth = eth interface you want bridged
>
> # if your machine has static ip address $ipaddr, with prefix length $len
> ifconfig_bridge0="inet $ipaddr/$len
>
> # if your machine is given a dynamic ip address
> #ifconfig_bridge0="DHCP"
>
> /etc/devfs.conf
> # create as many as you are likely to use
> own tap0 $user:$group # set to user/group of person invoking qemu
> own tap1 $user:$group
> own tap2 $user:$group
> own tap3 $user:$group
>
> /etc/sysctl.conf
> net.link.tap.user_open=1
> net.link.tap.up_on_open=1
>
> ln -s /usr/bin/true /etc/qemu-ifup
> ln -s /usr/bin/true /etc/qemu-ifdown
Hi,
I was thinking of using autobridge but eventually decided not to because:
- Putting an interface into bridge has certain drawbacks like disabling
checksum offloading. So I'd prefer not to bridge until I have to.
- I'm not sure whether it's generally acceptable to autobridge all tap*
devices. I might be OK with it now but I may not in the future and/or
other users may have different uses of tap* devices.
Problem with your devfs.conf is that it's static and thus the solution
is sort of halfway between not using autobridging at all (precreating a
few tap? devices and bridging them in rc.conf, like I found in many
examples on the internet). Again, it may be OK for you and me but I was
trying to find a more general solution.
Also, I'm not sure how is it possible that it works for you at all. I
tried "perm tap* 0660" but it did not work and then I learned
devfs.conf is only good for interfaces available at boot. That's why I
had to use /etc/devfs.rules config file.
> Note that on a wifi only machine you are only allowed one mac
> address for the wifi link so bridging with VMs won't work and
> you need NAT but you can still bridge all your tap interfaces
> together.
Thanks for the note, I wasn't aware of this.
Although I guess that if people run VMs on wifi connected machines they
would be happy with user mode networking.
> Also note that each qemu VM will need a unique mac address.
Yes, this is true and I wrote another script to help me automate it.
And MAC generation is "stolen" from you -- thank you for publishing! :-)
Well, the script is not that general and polished but here it is:
---
#!/bin/sh
#
# ~/bin/qemu_tap : mato [21-aug-2009]
#
# 1st parameter must be number of bridged NICs to create (tap interface)
# 3rd parameter should be primary / boot disk (MACs are generated based
on it)
#
[ "$1" -ge 0 ] || { echo "usage: ${0##*/} number_of_nics [qemu_options]"
>&2 ; exit 1 ; }
nics="$1"
shift
opts="$*"
vlan=0
macaddr()
{
echo "52:54:00:$(echo "$1" | md5 | cut -c1-6 | sed
's/\(..\)\(..\)/\1:\2:/')"
}
while [ $vlan -lt "$nics" ]
do
opts="$opts -net nic,vlan=$vlan,macaddr=$(macaddr "$(realpath
$2)-$vlan") -net tap,vlan=$vlan"
vlan="$(expr $vlan + 1)"
done
exec qemu $opts
---
I create a runscript for each VM I want to bridge as follows:
$ cat img/matoqemu
#!/bin/sh
qemu_tap 1 -hda ~/img/matoqemu_winxp-pro-en-vlp.raw.img -name
matoqemu/192.168.11.201 -alt-grab -kernel-kqemu -localtime -soundhw
es1370 -m 256 "$@"
For ad hoc VMs and ones I do not require to be bridged I happily use
qemu-launcher (though I haven't tried anything else and I would
certainly welcome port of qemuctl).
With regards,
Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?h6tfqf$kb0$1>