Bug 845137 - Guest OS cannot communicate outside of virtual subnet under fc17 as Host OS
Guest OS cannot communicate outside of virtual subnet under fc17 as Host OS
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
17
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Fedora Virtualization Maintainers
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-01 18:34 EDT by Andrew M. Shooman
Modified: 2013-02-05 11:21 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-05 11:21:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew M. Shooman 2012-08-01 18:34:38 EDT
Description of problem:
Guest OS cannot communicate outside of virtual subnet, 192.168.122.XXX.
VM networking is fine with fc16_64 as the Host OS, but has a problem with fc17_64 as the Host OS.


Version-Release number of selected component (if applicable):
Name        : qemu
Arch        : x86_64
Epoch       : 2
Version     : 1.0
Release     : 18.fc17


How reproducible:
1.  Define Guest OS with Virtual Machine Manager under Host OS fc16_64
2.  Test networking outside of virtual subnet with ping and dig
3.  Upgrade Host OS to fc17_64 using preupgrade
4.  Start same Guest OS with Virtual Machine Manager under Host OS fc17_64
5.  Test networking outside of virtual subnet with ping and dig


Actual results:
3 different Guest OSs (fc17_32, Win7_64, WinXP_32) are able to communicate outside of the virtual subnet 192.168.122.XXX under Host OS fc16_64 but not user Host OS fc17_64.


Expected results:
All 3 Guest OSs (fc17_32, Win7_64, WinXP_32) should have full network connectivity inside and outside of the virtual subnet 192.168.122.XXX under Host OS fc17_64.


Additional info:
Routing table for fc17_32 Guest OS under fc17_64 Host OS:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         MLTEST.clrcase. 0.0.0.0         UG    0      0        0 eth0
192.168.122.0   *               255.255.255.0   U     0      0        0 eth0

"MLTEST.clrcase." is a suspicious default gateway entry.
192.168.122.1 is the expected default gateway entry.

I tried to change this as follows:
route del default
route add default gw 192.168.122.1

The routing table output still shows "MLTEST.clrcase" after this change.  The networking behavior also did not change (i.e. no connection to the "outside world").

However, the default gateway entry in /proc/net/route seems normal:

Iface   Destination     Gateway         Flags   RefCnt  Use     Metric  Mask            MTU     Window  IRTT                  
                                     
eth0    00000000        017AA8C0        0003    0       0       0       00000000        0       0       0                     
                                                          
eth0    007AA8C0        00000000        0001    0       0       0       00FFFFFF        0       0       0


Hardware is Dell Precision T5500 with Xeon E5507x4 CPU.
Software is Linux d5160021 3.4.6-2.fc17.x86_64 #1 SMP Thu Jul 19 22:54:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

If you need any more information, please let me know.  Thanks.


Best Regards,

Andy Shooman
Comment 1 Andrew M. Shooman 2013-02-05 11:21:46 EST
qemu networking works fine as of version 1.0.1

Name        : qemu
Arch        : x86_64
Epoch       : 2
Version     : 1.0.1
Release     : 3.fc17

3.7.3-101.fc17.x86_64

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