On Wed, Jan 25, 2012 at 7:16 PM, Bruce Dubbs <[email protected]> wrote: > Bruce Dubbs wrote: >> Nathan Coulson wrote: >> >>> Not any time to proofread this, but this is what I use >>> >>> echo > /etc/qemu-ifup << "EOF" >>> ip addr add 0.0.0.0 dev $1 >>> ip link set $1 up >>> brctl addif br0 $1 >>> EOF >> >> Well I finally had an epiphany. The script goes on the host, not the >> client! Sometimes you just get going in the wrong direction ... and >> going .. and going. > > OK, thanks to Nathan, Qrux, a lot of reading, and a lot of > experimenting, I've got this working. My notes are below. I will be > adding bridge-utils and qemu-kvm to the book and show users how to set > it up. I won't use exactly the instructions below, but I'll use them > as a guide. > > I'll add the bridge service that Nathan wrote to the bootscripts. > > The capability this adds is the ability to use kvm/qemu to build LFS in > a controlled environment. One problem with kvm is that you can't, > AFAIK, cut and paste between the host and client window. Now a ssh > session from the host (or another system on the network) allows a nice > interface for building the book. LFS build LFS in a nice convenient way. > > -- Bruce > > > Set VT option in BIOS. > > Need bridge-utils-1.5.tar.gz > qemu-kvm-1.0.tar.gz > > groupadd -g 61 kvm > usermod -g kvm userid > > KERNEL > CONFIG_BRIDGE=y > CONFIG_STP=y > CONFIG_TUN=y > CONFIG_HAVE_KVM=y > CONFIG_KVM=y > CONFIG_KVM_INTEL=y > > # Installed in /opt/kvm > # Do some convenience things > > cd /opt/kvm/bin > sudo chmod 4755 qemu-system-x86_64 > ln -s qemu-system-x86_64 qemu > sudo chgrp kvm * > export PATH=/opt/kvm/bin:$PATH > > sysctl -w net.ipv4.ip_forward=1 > > # Set host interface to go through br0 instead of eth0 > > brctl addbr br0 > brctl addif eth0 > brctl stp br0 off > > ip link set br0 up > ip link set eth0 up > > ip addr add $HOSTIP dev br0 > ip route add default via $GATEWAY dev br0 > > # Create /etc/qemu-ifup > #!/bin/bash > > switch=br0 > > if [ -n "$1" ]; then > # Add new tap0 interface to bridge > /usr/bin/sudo /sbin/ip link set $1 up > sleep 0.5s > /usr/bin/sudo /usr/sbin/brctl addif $switch $1 > else > echo "Error: no interface specified" > exit 1 > fi > > exit 0 > > # Create /etc/qemu-ifdown > #!/bin/bash > > switch=br0 > > if [ -n "$1" ];then > # Remove tap0 interface from bridge > /usr/bin/sudo /usr/sbin/brctl delif $switch $1 > else > echo "Error: no interface specified" > exit 1 > fi > > exit 0 > > # Start qemu > > qemu -hda fedora.img -m 1G -net nic -net tap > > On client: > DHCP works by default on Fedora > Set up as a static IP on client > Start ssh (service ssh start, or set to come up automatically) > Turn off firewall (service iptables stop) on client for incoming ssh and > other services
Great to hear it is working. BTW, any thoughts on how bridgeutils will be used by the bootscripts? As nice as my script was, it did require 2 seperate ifconfig.br0 files. (Well, easier w/ Qrux's changes, but we wouldn't want to add support for every variation of network addresses into the bind script [dhcp, ipv4, ipv6]). perhaps, something like BRIDGE="eth0,eth1" with the logic programmed into ifup/ifdown, That way, any network service script can use this feature if bridge-utils is installed (and give a friendly warning if it is not installed) (I don't like the idea of network specific code in ifup/ifdown, but it feels right for bridging. My alternative suggestion would be to add it to each & every service script [which I vote against]). service scripts were designed to setup an address onto an existing interface. As an alternative (but I think this may be overkill), I wonder if bringing up interfaces in 2 stages would be worth it... 1) prep or create interface (such as br0), 2) setup address (such as dhcp configured IPV4). /etc/sysconfig/network-devices/ifconfig.br0 INTERFACE=bridge BRIDGE="eth0,eth1" SERVICE=dhcp it would first run /lib/services/bridge, then run /lib/services/dhcp -- Nathan Coulson (conathan) ------ Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
