qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: Network bridging without adding bridge with brctl,


From: Arnd Bergmann
Subject: Re: [Qemu-devel] Re: Network bridging without adding bridge with brctl, possible?
Date: Mon, 21 Feb 2011 13:07:38 +0100
User-agent: KMail/1.12.2 (Linux/2.6.37; KDE/4.3.2; x86_64; ; )

On Monday 21 February 2011, Jan Kiszka wrote:
> > 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 command
> > line configured) and used tap interface from macvtap0 (as no second tap
> > devices shows up)
> > 
> > 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 with
> > 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 used
> > 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.
> > 
> > @Arnd: Can you explain a setup in detail which should work also with
> > host/guest communication. Thnx.
> > 
> > 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.

We had a few bugs in .34, but it should work in general.

One thing to make sure is that the host has connectivity through the
macvlan interface and the lower interface (eth0) has no IP address assigned
but is 'up'.

It could also be a bug in the NIC, you could try to set the NIC into
promiscious mode using ethtool to work around that.

Also, the lower interface must not be connected to a bridge device.

        Arnd



reply via email to

[Prev in Thread] Current Thread [Next in Thread]