From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41865 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PrDcl-0006j8-JD for qemu-devel@nongnu.org; Sun, 20 Feb 2011 13:03:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PrDFv-0000iA-VU for qemu-devel@nongnu.org; Sun, 20 Feb 2011 12:39:37 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:42659) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PrDFv-0000ho-Ib for qemu-devel@nongnu.org; Sun, 20 Feb 2011 12:39:35 -0500 Message-ID: <4D6151CF.3070104@web.de> Date: Sun, 20 Feb 2011 18:39:27 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Network bridging without adding bridge with brctl, possible? References: <4D60E26D.3060202@web.de> <4D6121F1.1080900@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF98284C72539F4853AB1470B" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerhard Wiesinger Cc: qemu-devel@nongnu.org, Arnd Bergmann This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF98284C72539F4853AB1470B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-02-20 16:19, Gerhard Wiesinger wrote: > On Sun, 20 Feb 2011, Jan Kiszka wrote: >=20 >> On 2011-02-20 13:49, Gerhard Wiesinger wrote: >>> On Sun, 20 Feb 2011, Jan Kiszka wrote: >>> >>>> On 2011-02-19 20:32, Gerhard Wiesinger wrote: >>>>> Hello, >>>> http://virt.kernelnewbies.org/MacVTap >>>> >>>> ip link add link eth1 name macvtap0 type macvtap mode bridge >>>> ip link add link eth1 name macvlan0 type macvlan mode bridge >>>> ifconfig macvlan0 ... >>> >>> >>> Hello Jan, >>> >>> iproute2 2.6.37 is needed! >>> http://devresources.linuxfoundation.org/dev/iproute2/download/iproute= 2-2.6.37.tar.bz2 >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> 1.) Only macvtap interface used >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> For me it was just unlogically to use a VLAN type interface. Therefor= e I >>> tried the following which worked nearly: >>> /root/download/iproute2/iproute2-2.6.37/ip/ip link add link eth0 name= >>> macvtap0 type macvtap mode bridge >>> /root/download/iproute2/iproute2-2.6.37/ip/ip link set macvtap0 addre= ss >>> 1a:46:0b:ca:bc:7b up >>> ip link show macvtap0 >>> ls -l /dev/tap* >>> # crw-rw---- 1 root root 249, 8 Feb 20 13:07 /dev/tap8 >>> qemu-system-x86_64 ... some params ... -net >>> nic,model=3De1000,macaddr=3D1a:46:0b:ca:bc:7b -net tap,fd=3D3 3<>/dev= /tap8 >>> >>> Booting Knoppix 6.2 with ping is ok, MAC address is also correct on >>> second host. >>> >>> Only problem is that from host to guest no networking is possible (on= ly >>> from guest to other host). >>> >>> Any ideas? I guess some forwarding is missing? iptables forward missi= ng? >> >> To my understanding macvlan(+macvtap) devices in bridge mode can only >> talk to the outer world via the physical device they are attached to o= r >> other macvlan nodes attached to that same device. Therefore... >> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> 2.) Only macvtap interface used >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> /root/download/iproute2/iproute2-2.6.37/ip/ip link add link eth0 name= >>> macvtap0 type macvtap mode bridge >>> /root/download/iproute2/iproute2-2.6.37/ip/ip link set macvtap0 addre= ss >>> 1a:46:0b:ca:bc:7b up >>> #/root/download/iproute2/iproute2-2.6.37/ip/ip link add link eth0 nam= e >>> macvlan0 type macvlan mode bridge >>> #/root/download/iproute2/iproute2-2.6.37/ip/ip link set macvlan0 addr= ess >> >> ...the need for this additional macvlan device. You just have to set a= n >> IP on macvlan0. >=20 > Negative. >=20 > Tried: > /root/download/iproute2/iproute2-2.6.37/ip/ip link add link eth0 name > macvtap0 type macvtap mode bridge > /root/download/iproute2/iproute2-2.6.37/ip/ip link set macvtap0 address= > 1a:46:0b:ca:bc:7b up > /root/download/iproute2/iproute2-2.6.37/ip/ip link add link eth0 name > macvlan0 type macvlan mode bridge > /root/download/iproute2/iproute2-2.6.37/ip/ip link set macvlan0 address= > 1a:46:0b:ca:bc:7c up > ip link show macvtap0 > ip link show macvlan0 > ls -l /dev/tap* > # crw-rw---- 1 root root 249, 10 Feb 20 15:45 /dev/tap10 > ifconfig macvlan0 192.168.0.23 up >=20 > DHCP is configure for 1a:46:0b:ca:bc:7b mac for 192.168.0.23 ip and > 1a:46:0b:ca:bc:7c mac for 192.168.0.24 ip. >=20 > # works without outer connection > qemu-system-x86_64 ... some params ... -net > nic,model=3De1000,macaddr=3D1a:46:0b:ca:bc:7b -net tap,fd=3D3 3<>/dev/t= ap10 >=20 > # 2nd try: > ifconfig macvlan0 192.168.0.24 up > # No network at all > qemu-system-x86_64 ... some params ... -net > nic,model=3De1000,macaddr=3D1a:46:0b:ca:bc:7c -net tap,fd=3D3 3<>/dev/t= ap10 >=20 > Seems to me quite logically because macvtap0 (and not macvlan0) is > associated with /dev/tap10 but with another mac address set in KVM. >=20 > Any furher ideas? As you already noticed: you mixed up the MAC addresses. KVM's must be the same as used for its frontend macvtap. The macvlan is only for the host and has a separate one. Jan --------------enigF98284C72539F4853AB1470B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1hUdUACgkQitSsb3rl5xTmSwCfaqxbGW4VxnO5H8JwGQkLP5ZA 9aQAoM4AtUxQSgdKWkbX+BuAQphiTUIQ =ydXL -----END PGP SIGNATURE----- --------------enigF98284C72539F4853AB1470B--