Bug 620246 - qemu-kvm secondary interface eth1 not working on guest vm
Summary: qemu-kvm secondary interface eth1 not working on guest vm
Alias: None
Product: Fedora
Classification: Fedora
Component: qemu   
(Show other bugs)
Version: 13
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Justin M. Forbes
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-01 18:35 UTC by Muzi
Modified: 2013-01-09 11:38 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-12 14:33:46 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Muzi 2010-08-01 18:35:48 UTC
Description of problem: qemu-kvm running guest are unable to run functional with additional interface (eth1), arp issue come for eth1 and no communication on eth1, here below in detail in Additional info section.

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

How reproducible:

Steps to Reproduce:
1. Setup kvm structure for kvm guest,and run below command for setup two nic's
2. /usr/bin/qemu-kvm -M pc -m 256 -smp 1 -name myguest1 -uuid 5dcb91e1-0a1e-8846-3859-ee03cb362427 -nographic -monitor unix:/var/lib/libvirt/qemu/myguest1.monitor,server,nowait -boot c -drive file=/dev/vmdata/vm.root,if=ide,index=0,boot=on -drive file=/dev/vmdata/vm.var,if=ide,index=1 -drive file=/dev/vmdata/vm.swap,if=ide,index=3 -net nic,macaddr=52:54:00:ea:aa:fe,vlan=0,name=nic0 -net tap,ifname=tap3,script=/etc/KVM/vm-tap3.sh,vlan=0,name=tap3 -net nic,macaddr=52:54:00:a7:9b:c1,vlan=1,name=nic1 -net tap,ifname=tap30,script=/etc/KVM/vm-tap30.sh,vlan=1,name=tap30 -serial pty -parallel none -usb &
3. Now give ip on eth1 on kvm guest myguest and its not pining/working for outerworld, Note: my setup contains public IP's i am not using NAT
Actual results:

[root@host ~]# arp -e
Address HWtype HWaddress Flags Mask Iface
x.x.x.x ether 52:54:00:56:40:56 C tap1
x.x.x.x (incomplete) tap30
x.x.x.x ether 00:d0:d3:80:64:0a C eth0

Expected results:
arp entry should be define for eth1 as like for eth0

Additional info:

I am running KVM on FC12 with tap networking in routed mode. All is working now i am facing problem to setup two NIC's on kvm guest. Here below little detail

Now tap3 is for eth0 and tap30 for eth1 for vm child, and desire scripts use to create tap and put routes automatically, as all is working f9. Now when guest boot two interfaces eth0 and eth1, now eth0 is working f9 , but when i assign ip on eth1 and up interface its not pinging/working inside mother/outerworld

After some more diagnose via tcpdump and arp info, i come to know that on KVM host, tap30 which is used for eth1 on guest vm, qemu-kvm unable to define its arp entry

[root@host ~]# arp -e
Address HWtype HWaddress Flags Mask Iface
x.x.x.x ether 52:54:00:56:40:56 C tap1
x.x.x.x (incomplete) tap30
x.x.x.x ether 00:d0:d3:80:64:0a C eth0

and on KVM guest on eth1, tcpdump shows arp who has replies, as i don't now why its fails or treat like eth0 , as beofre when i run guests using virsh start guest-vm then all is working f9 , but when i start vm through above script qemu-kvm, its unable to set properly eth1 for guest vm, any ideas or suggestions please ????????


Comment 1 Muzi 2010-08-02 17:34:55 UTC
Any thoughts / Any ideas ?, we are very badly suffer from this problem


Comment 2 Muzi 2010-09-07 19:21:54 UTC
Can any one facing this issue, ?? , or any idea about secondary interface this problem, as per above detail ??


Comment 3 Jeff Raber 2010-09-12 20:02:50 UTC

Comment 4 Muzi 2010-09-16 22:29:38 UTC
(In reply to comment #3)
> Version=12

Hi Jeff

What is mean by Version=12 ? which package its relate ? or what you want to told ?


Comment 5 Jeff Raber 2010-09-16 23:27:09 UTC
Sorry for the confusion.  I was being lazy when I did that.

When creating bugs in the Redhat/Fedora bugzilla, the number in the Version selector field is the version of the Fedora distribution as a whole (12, 13, 14, Rawhide).

When you opened the bug, you had set version=1.  (Fedora Core 1 is no longer being maintained and any new bugs for that version would be CLOSED as WONTFIX).  I fixed this using the version information that you supplied in the bug description (FC12).

Comment 6 Muzi 2010-09-23 20:15:08 UTC
Hi Jeff

Thanks for the update, i forget to set the right version earlier.Can you face the same problem ? or any update is appreciate on this thread.


Comment 7 Muzi 2010-10-08 20:42:39 UTC
Any updates on this highly appreciated, can some one please test this ?, as we are facing to much problem to bind ips are on secondary interface.


Comment 8 Bug Zapper 2010-11-03 11:21:29 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 9 Muzi 2010-11-23 18:04:33 UTC
Same response in FC13.

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