From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49848 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PrRO2-00051V-1l for qemu-devel@nongnu.org; Mon, 21 Feb 2011 03:44:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PrRO0-0000Ym-L7 for qemu-devel@nongnu.org; Mon, 21 Feb 2011 03:44:53 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:55310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PrRO0-0000Yi-2W for qemu-devel@nongnu.org; Mon, 21 Feb 2011 03:44:52 -0500 Message-ID: <4D622602.7070009@web.de> Date: Mon, 21 Feb 2011 09:44:50 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Network bridging without adding bridge with brctl, possible? References: <4D6151CF.3070104@web.de> <201102202233.37208.arnd@arndb.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF869437A70A02CF37FCADDD1" 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) --------------enigF869437A70A02CF37FCADDD1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-02-21 07:40, Gerhard Wiesinger wrote: > On Sun, 20 Feb 2011, Arnd Bergmann wrote: >=20 >> On Sunday 20 February 2011, Gerhard Wiesinger wrote: >>>>> qemu-system-x86_64 ... some params ... -net >>>>> nic,model=3De1000,macaddr=3D1a:46:0b:ca:bc:7c -net tap,fd=3D3 3<>/d= ev/tap10 >>>>> >>>>> Seems to me quite logically because macvtap0 (and not macvlan0) is >>>>> associated with /dev/tap10 but with another mac address set in KVM.= >>>>> >>>>> Any furher ideas? >>>> >>>> As you already noticed: you mixed up the MAC addresses. KVM's must b= e >>>> the same as used for its frontend macvtap. The macvlan is only for t= he >>>> host and has a separate one. >>> >>> I think I did everyting right in the last 1st try but it still didn't= >>> work: >>> 1.) macvtap0: MAC: 1a:46:0b:ca:bc:7b >>> 2.) macvlan0: MAC: 1a:46:0b:ca:bc:7c, 192.168.0.23 >>> 3.) KVM: MAC: 1a:46:0b:ca:bc:7b, assigned IP from DHCP: >>> 1a:46:0b:ca:bc:7b >>> (looks like an IP address conflict inside guest and outside?) >>> >>> That should be as you explained, right? >> >> The qemu command above has the 7c mac address, which does not match. >> Do you see the interface in the guest using "ip link show" ? >=20 > Only the second try had 7c mac address. 1st try had 7b mac address. >=20 > Now I tried the following still with same success that host/guest > communication (because of missing hairpin mode of the switch) is NOT > possible. > ############################################################ > # Used 7c mac in KVM > ############################################################ > # No need for bridge mode and iproute2 2.6.37 > ip link add link eth0 name macvtap0 type macvtap > ip link set macvtap0 address 1a:46:0b:ca:bc:7b up > ip link add link macvtap0 name macvlan0 type macvlan > 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, 18 Feb 21 07:21 /dev/tap18 > ifconfig macvlan0 192.168.0.23 up > /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 ... > -net nic,model=3Dpcnet,macaddr=3D1a:46:0b:ca:bc:7c -net tap,fd=3D3 > # Guest has 7c mac, external traffic NOT ok > ip link delete macvlan0 type macvlan > ls -l /dev/tap* > # Still present > # crw-rw---- 1 root root 249, 18 Feb 21 07:21 /dev/tap18 > ip link delete macvtap0 type macvtap > ls -l /dev/tap* > # ls: cannot access /dev/tap*: No such file or directory > ############################################################ > # Used 7b mac in KVM > ############################################################ > # No need for bridge mode and iproute2 2.6.37 > ip link add link eth0 name macvtap0 type macvtap > ip link set macvtap0 address 1a:46:0b:ca:bc:7b up > ip link add link macvtap0 name macvlan0 type macvlan > 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, 18 Feb 21 07:21 /dev/tap18 > ifconfig macvlan0 192.168.0.23 up > /root/download/qemu/git/qemu-kvm/x86_64-softmmu/qemu-system-x86_64... > -net nic,model=3Dpcnet,macaddr=3D1a:46:0b:ca:bc:7b -net tap,fd=3D3 > # Guest has 7b mac, external traffic ok, internal not > ip link delete macvlan0 type macvlan > ls -l /dev/tap* > # Still present > # crw-rw---- 1 root root 249, 18 Feb 21 07:21 /dev/tap18 > ip link delete macvtap0 type macvtap > ls -l /dev/tap* > # ls: cannot access /dev/tap*: No such file or directory > ############################################################ >=20 > Now I think I tried all useful possible combinations: > 1.) macvtap0 and macvlan0 in bridged and non bridge mode > 2.) macvlan0 based on eth0 or based on macvtap0 > 3.) Using and ip address on macvlan0 or not (tried both for 7b mac and > 7c mac) > 4.) Using 7b and 7c mac address in KVM (MAC in KVM is always the comman= d > line configured) and used tap interface from macvtap0 (as no second tap= > devices shows up) >=20 > Summary: > 1.) Using macvtap0 only with 7b mac on interface and also at qemu works= > well in bridged mode as well as non bridged mode but with limitation no= > guest/host communication possible, used interface in KVM is tap > interface created by macvtap0. Quite logically that it doesn't work wit= h > guest/host because of missing hairpin mode on the switch. But according= > to http://virt.kernelnewbies.org/MacVTap bridge mode should work even > without hairpinning available on the switch. > 2.) macvlan0 doesn't create any tap interface therefore it can't be use= d > as a device on KVM. > 3.) Using 7c mac address in KVM doesn't work at all regardsless of > setting ip addresses on macvlan0 or any other setup. >=20 > @Arnd: Can you explain a setup in detail which should work also with > host/guest communication. Thnx. >=20 > Any further ideas? > Which kernel is needed to work? > (current: 2.6.34.7-56.fc13.x86_64) Actually, I tried this successfully over a 2.6.38-rcX, but I have no idea what changes related to macvlan/tap went in since .34 and if this is required for this. Jan --------------enigF869437A70A02CF37FCADDD1 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/ iEYEARECAAYFAk1iJgIACgkQitSsb3rl5xRUAQCdHu3TuVrhOTADCPGSzbrlFp3N OHgAoMhnJUZLzUsgEfUBhLYvddBZur7C =OCkh -----END PGP SIGNATURE----- --------------enigF869437A70A02CF37FCADDD1--