Bug 239558 - Cannot get networking in virt-manager KVM sessions
Summary: Cannot get networking in virt-manager KVM sessions
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Berrange
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-05-09 14:15 UTC by Josh Boyer
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-09 15:26:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sysctl -a output from host machine (27.97 KB, text/plain)
2007-05-09 14:17 UTC, Josh Boyer
no flags Details
tcpdump from host eth1 interface (336.71 KB, text/plain)
2007-05-09 14:46 UTC, Josh Boyer
no flags Details
tcpdump from host vibr0 interface (4.35 KB, text/plain)
2007-05-09 14:46 UTC, Josh Boyer
no flags Details

Description Josh Boyer 2007-05-09 14:15:48 UTC
Description of problem:

With the latest virt-manager, kvm, libvirt packages I still cannot get network
traffic in KVM guests.  DNS lookups succeed, however basic ping traffic always
fails.

Version-Release number of selected component (if applicable):

[root@zod ~]# rpm -q libvirt
libvirt-0.2.2-3.fc7
[root@zod ~]# rpm -q virt-manager
virt-manager-0.4.0-1.fc7
[root@zod ~]# rpm -q kvm
kvm-19-2


How reproducible:

Always

Steps to Reproduce:
1. Start virt-manager
2. Start fedora 7 KVM instance
3.
  
Actual results:

DNS lookups work, basic ping traffic does not

Expected results:

Networking works

Additional info:

Host network information
-------------------------

[root@zod ~]# ifconfig
eth1      Link encap:Ethernet  HWaddr 00:15:58:2A:11:46  
          inet addr:<edited>  Bcast:<edited>  Mask:255.255.255.0
          inet6 addr: fe80::215:58ff:fe2a:1146/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:122991 errors:0 dropped:0 overruns:0 frame:0
          TX packets:95077 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:155878426 (148.6 MiB)  TX bytes:7207768 (6.8 MiB)
          Base address:0x3000 Memory:ee000000-ee020000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:5650 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5650 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:58898367 (56.1 MiB)  TX bytes:58898367 (56.1 MiB)

virbr0    Link encap:Ethernet  HWaddr 5E:09:32:99:81:94  
          inet addr:192.168.122.1  Bcast:192.168.122.255  Mask:255.255.255.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:4049 (3.9 KiB)  TX bytes:9819 (9.5 KiB)

vnet0     Link encap:Ethernet  HWaddr 5E:09:32:99:81:94  
          inet6 addr: fe80::5c09:32ff:fe99:8194/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:4413 (4.3 KiB)  TX bytes:5591 (5.4 KiB)

[root@zod ~]# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.5e0932998194       no              vnet0

[root@zod ~]# iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 1943 packets, 313K bytes)
 pkts bytes target     prot opt in     out     source               destination
        

Chain POSTROUTING (policy ACCEPT 333 packets, 20493 bytes)
 pkts bytes target     prot opt in     out     source               destination
        
    3   786 MASQUERADE  0    --  *      *       192.168.122.0/24     0.0.0.0/0 
         

Chain OUTPUT (policy ACCEPT 337 packets, 21491 bytes)
 pkts bytes target     prot opt in     out     source               destination
        

[root@zod ~]# iptables -L -n -v
Chain INPUT (policy ACCEPT 126K packets, 214M bytes)
 pkts bytes target     prot opt in     out     source               destination
        
    2   134 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0  
        udp dpt:53 
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0  
        tcp dpt:53 
    2   656 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0  
        udp dpt:67 
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0  
        tcp dpt:67 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
        
    0     0 ACCEPT     0    --  *      virbr0  0.0.0.0/0           
192.168.122.0/24    state RELATED,ESTABLISHED 
    2   168 ACCEPT     0    --  virbr0 *       192.168.122.0/24     0.0.0.0/0  
        
    0     0 ACCEPT     0    --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0  
        
    0     0 REJECT     0    --  *      virbr0  0.0.0.0/0            0.0.0.0/0  
        reject-with icmp-port-unreachable 
    0     0 REJECT     0    --  virbr0 *       0.0.0.0/0            0.0.0.0/0  
        reject-with icmp-port-unreachable 

Chain OUTPUT (policy ACCEPT 102K packets, 65M bytes)
 pkts bytes target     prot opt in     out     source               destination

Comment 1 Josh Boyer 2007-05-09 14:17:01 UTC
Created attachment 154400 [details]
sysctl -a output from host machine

Comment 2 Daniel Berrange 2007-05-09 14:28:56 UTC
What kernel are you running on the host ?

Does doing 'ethtool -K <dev> tx off' on any (or all) or  eth0, virbr0, vnet0
make any difference ?

The IPtables rules are the correct default setup. The sysctl log shows ip
forward is enabled & there's a couple of packets matching the FORWARD rule for
outgoing traffic. Nothing coming back in on the FORWARD chain though which
matches your report of no ping replies.

Finally, can you try capturing 

 tcpdump -i eth0 -s 1000 -XX -n -v
 tcpdump -i virbr0 -s 1000 -XX -n -v

On the host while the ping is going on.

Oh, and 192.168.122.0/24 clash with any IP addrs used on your local LAN ?


Comment 3 Josh Boyer 2007-05-09 14:44:52 UTC
(In reply to comment #2)
> What kernel are you running on the host ?

[root@zod ~]# uname -a
Linux zod.rchland.ibm.com 2.6.21-1.3116.fc7 #1 SMP Thu Apr 26 10:36:44 EDT 2007
i686 i686 i386 GNU/Linux

> Does doing 'ethtool -K <dev> tx off' on any (or all) or  eth0, virbr0, vnet0
> make any difference ?

Not that I can see, no.

> The IPtables rules are the correct default setup. The sysctl log shows ip
> forward is enabled & there's a couple of packets matching the FORWARD rule for
> outgoing traffic. Nothing coming back in on the FORWARD chain though which
> matches your report of no ping replies.
> 
> Finally, can you try capturing 
> 
>  tcpdump -i eth0 -s 1000 -XX -n -v
>  tcpdump -i virbr0 -s 1000 -XX -n -v

Will attach these shortly.

> On the host while the ping is going on.
> 
> Oh, and 192.168.122.0/24 clash with any IP addrs used on your local LAN ?

Shouldn't, no.



Comment 4 Josh Boyer 2007-05-09 14:46:06 UTC
Created attachment 154402 [details]
tcpdump from host eth1 interface

Comment 5 Josh Boyer 2007-05-09 14:46:51 UTC
Created attachment 154403 [details]
tcpdump from host vibr0 interface

Comment 6 Josh Boyer 2007-05-09 15:26:13 UTC
ARGH!  Nevermind.

It seems the site LAN here blocks ICMP traffic in general.  The host can't even
get ping replies from machines outside of the site.  I can get networking in the
guest just fine.

So much for using ping as a network test.  Sorry for wasting your time.


Note You need to log in before you can comment on or make changes to this bug.