KVM Networking Hell

Jamie McDonald jmack at iclebyte.com
Wed Jun 9 22:09:48 UTC 2010


Good timing! I was just about to write another email as I've been playing
with this all evening - alas still no joy.

On Wed, Jun 9, 2010 at 10:24 PM, Soren Hansen <soren at ubuntu.com> wrote:

> On Wed, Jun 09, 2010 at 02:57:45PM +0100, Jamie McDonald wrote:
> > The output of 'brctl show' on the host is as follows
> >
> > ## START brctl output ###
> >
> > $brctl show
> > bridge name     bridge id               STP enabled     interfaces
> > br0             8000.001999705a61       no                  eth0
> >
> > vnet0
> > ## END brctl output ##
> I'm not sure if this output got linebroken somewhere. Can you perhaps
> make sure the terminal you're using is large enough to hold the output
> and put it on a pastebin so we can be sure noone's e-mail application is
> messing with the formatting?

 I have pasted a new copy here: http://pastebin.org/322148

> > From looking at this it looks like I should have my guest configured
> > to use the vnet0 interface instead of br0?
> No. vnet0 /is/ your guest. The virtual machines use tap devices for
> networking. Think of vnet0 as the host end of the virtual network cable
> between the guets and the host. It is meant to be connected to br0 such
> that eth0 and vnet0 both are "connected".

Thanks for your explanation - this makes more sense. Based on what you have
said then the VM is having the vnet0 tap interface created and successfully
attached to the br0 interface along with eth0 as per the pastebin mentioned

> > brtables has not been modified in any way.
> Ok. And you haven't used Eucalyptus? It's the only thing I know of that
> might fiddle with brtables behind the scenes.

No I have not used Eucalyptus - this is a standard 9.10 build of Ubuntu
server from Fasthosts.

> What is eth0 on the host, by the way? What kind of NIC?
> # dmesg | grep eth0
[    3.694657] 0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1)
[    3.694659] 0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
[    3.694812] 0000:00:19.0: eth0: MAC: 7, PHY: 8, PBA No: ffffff-0ff
[    9.403673] device eth0 entered promiscuous mode
[    9.476752] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   11.045806] 0000:00:19.0: eth0: Link is Up 100 Mbps Full Duplex, Flow
Control: None
[   11.045808] 0000:00:19.0: eth0: 10/100 speed: disabling TSO
[   11.046300] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   11.046373] br0: port 1(eth0) entering forwarding state
[   21.972047] eth0: no IPv6 routers present

During my experiments this afternoon I have actually become more confused.
I have removed all firewall rules from the host in order to test as
suggested by Alex (thankyou for your input kind sir). IP Forwarding is
enabled (even though it should make no difference) and the following rules
were added (although again I really don't think I should need them).

/sbin/iptables -A FORWARD -d -j ACCEPT
/sbin/iptables -A FORWARD -s -j ACCEPT

On the host machine I started listening for guest traffic on the eth0
interface using the following: tcpdump -i eth0 'host'
>From the VM I then executed 'ping'. The TCP dump of eth0 on the
host shows the ARP's being received by the host, however no response is ever
sent - this always results in a 'destination host unreachable' message on
the VM. This is obviously the same for any IP address on the internet.

# tcpdump -i eth0 'host'
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
23:04:33.961261 arp who-has server88-208-248-1.live-servers.net tell
23:04:34.961244 arp who-has server88-208-248-1.live-servers.net tell
23:04:35.961234 arp who-has server88-208-248-1.live-servers.net tell
23:04:36.971239 arp who-has server88-208-248-1.live-servers.net tell
23:04:37.971239 arp who-has server88-208-248-1.live-servers.net tell
23:04:38.971240 arp who-has server88-208-248-1.live-servers.net tell

Any other suggestions I could try? Is there anything which Fasthosts could
have in place which could inhibit a bridged network from operating

Kind Regards
- An increasingly insane Jamie.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-server/attachments/20100609/df26260e/attachment.html>

More information about the ubuntu-server mailing list