Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a KVM host (at 192.168.0.10) that currently has one working KVM guest (at 192.168.0.12). On attempting to install a new KVM guest today, I reached a problem where the network on the new guest only partially works.

The only things I can access from the new guest are resources inside the network. Trying to access any other network resources (including those past the gateway) results in 100% packet loss to the destination.

The guests connect through a bridge at br0 that uses eth2 to access the network.

The host network works as expected, and the network on the other (only one, currently) guest, also connecting through the same bridge, works. Shutting down the working guest does not fix the problem.

Both of the guests get their network details over DHCP.

Running tcpdump from the host on the virtual interface for the guest shows the guest attempting to communicate with the outside world, and only getting responses from the host and the gateway.


Host

The guest with the problem is currently connecting through vnet0.

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:4f:34:dc:79 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:4f:34:dc:7b brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
    link/ether 00:15:17:6a:fb:ee brd ff:ff:ff:ff:ff:ff
13: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:15:17:6a:fb:ee brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.10/24 brd 192.168.0.255 scope global br0
    inet6 fe80::215:17ff:fe6a:fbee/64 scope link
       valid_lft forever preferred_lft forever
24: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 500
    link/ether fe:54:00:fc:0f:07 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fefc:f07/64 scope link
       valid_lft forever preferred_lft forever
25: vnet1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN qlen 500
    link/ether fe:54:00:89:8e:17 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe89:8e17/64 scope link
       valid_lft forever preferred_lft forever
# ip route
default via 192.168.0.202 dev br0
192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.10
# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto br0
iface br0 inet dhcp
    bridge_ports    eth2
    bridge_stp      off
    bridge_maxwait  0
    bridge_fd       0
# brctl show
bridge name bridge id       STP enabled interfaces
br0     8000.0015176afbee   no      eth2
                            vnet0
                            vnet1

Non-working guest

Note that the non-working guest uses busybox ip.

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisk pfifo_fast qlen 1000
    link/ether 52:54:00:fc:0f:07 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.27/24 scope global eth0
    inet6 fe80::5054:ff:fefc:f07/64 scope link
       valid_lft forever preferred_lft forever
# ip route
default via 192.168.0.202 dev eth0
192.168.0.0/24 dev eth0  src 192.168.0.27

Working guest

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:89:8e:17 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.12/24 brd 192.168.0.255 scope global eth0
    inet6 fe80::5054:ff:fe89:8e17/64 scope link
       valid_lft forever preferred_lft forever
# ip route
default via 192.168.0.202 dev eth0
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.12

Both the host and the guests run Debian Wheezy.

I do not see any misconfiguration in the details posted, especially bearing in mind that the exact same setup method worked recently to install the other KVM guest (and continues to work even now). What could be the cause of this problem, and how can I fix it?

share|improve this question
    
Let us see brctl show on the host. And, what OS is this non-working guest? –  Michael Hampton Aug 3 '13 at 15:50
    
@MichaelHampton The guest is running Wheezy, but I have tried with other operating systems, with the same effects. I added brctl show to my question, thanks! –  Chris Aug 3 '13 at 15:52

1 Answer 1

up vote 3 down vote accepted

STP should be enabled on the bridge used for KVM virtual machines.

Fix this in your /etc/network/interfaces file:

    bridge_stp      on

Enable it at runtime without restarting the network service:

# brctl stp br0 on
share|improve this answer
    
This appears to have fixed it, thanks! I'm curious, why is STP required in this case? –  Chris Aug 3 '13 at 15:59
2  
I think you'd have to ask the maintainers, because it doesn't make any sense to me either. –  Michael Hampton Aug 3 '13 at 16:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.