(Note: Replying as HTML because OP is using HTML).
On 6/12/2012 1:14 AM, Supriya Kher wrote:
Hi everyone,
I have an issue with the tap interfaces in QEMU.
Setup Description:
Here is the long issue description to give you some background:
I have a Ubuntu 11.04 host running QEMU emulator
(qemu-system-x86_64. Qemu version 0.14.0)
The VM running on this host machine has an internal VM running a
second Linux operating system.
This is a VM inside a VM architecture, it being so for a reason.
Now, consider two such virtual machines running on this Ubuntu
host.
Both these VMs talk to each other via bridged interfaces.
Please clarify which of the following ASCII ART diagrams describe
your setup?:
Diagram 1:
+----------------------Some unknown
box----------------------+
| +-----------------------Ubuntu box-----------------------+ |
| | +----------VM A----------+ +----------VM B----------+ | |
| | | | | | | |
| | +------------------------+ +------------------------+ | |
| +--------------------------------------------------------+ |
+------------------------------------------------------------+
Diagram 2:
+-------------------------Ubuntu
box-------------------------+
| +-----------VM A-----------+ +-----------VM B-----------+ |
| | +--VM A1--+ +--VM A2--+ | | +--VM A1--+ +--VM A2--+ | |
| | | | | | | | | | | | | |
| | +---------+ +---------+ | | +---------+ +---------+ | |
| +--------------------------+ +--------------------------+ |
+------------------------------------------------------------+
Some other other diagram?
brctl show on Ubuntu host:
brctl show
bridge name bridge id STP enabled
interfaces
base_br6 8000.12b225a87738 no
btap_6_3
btap_6_7
The VMs running on this Ubuntu Host are:
1) VM_A
brctl show on VM_A
bridge name bridge id STP enabled
interfaces
base_br0 8000.001cae060703 no btap1
btap2
eth3
VM_A is also running QEMU emulator to host another VM
( alias internal guest or VM_A_Internal )
tipc-config -l -netid -addr -n issued on VM_A_Internal
Links:
broadcast link: up
current network id: 7777
node address: <6.1.7>
Neighbors:
No nodes found.
eth0 on VM_A_Internal is configured as the bearer interface
that sends out
TIPC neighbor discovery packets to detect its neighbor and
locate VM_B_Internal as its neighbor.
Similar settings applicable to VM_B.
2) VM_B - running QEMU emulator to host VM_B_Internal
brctl show on VM_B
bridge name bridge id STP enabled
interfaces
base_br0 8000.001cae060300 no btap1
btap2
eth3
tipc-config -l -netid -addr -n issued on VM_B_Internal
Links:
broadcast link: up
current network id: 7777
node address: <6.1.3>
Neighbors:
No nodes found.
eth0 on VM_B_Internal is configured as the bearer interface
that sends out TIPC neighbor discovery packets
to detect its neighbor and locate VM_A_Internal as its
neighbor.
ISSUE:
Now the issue is that all these packets ( TIPC control packets )
generated by the inner guest VMs are being
dropped by the tap interfaces on VM_A and VM_B ( confirmed
by the Rx drop count and Tx drop count shown by
netstat -i command) The host Ubuntu system also reports a drop of
Rx & Tx packets at the base_br6 bridge.
How do we avoid the packet drops at the tap interfaces created by
QEMU ? Am I missing something here ?
Note: The two inner guest VMs can see each other. Pinging the IP
Addresses configured on the btap<x> interface works.
However the neighborhood detection does not, indicating that these
packets alone are being dropped. Firewall on the host
has been configured to FORWARD incoming and not REJECT/DROP any
packet.
Have you looked at all the *tables on your system (iptables,
ip6tables, arptables, ebtables etc.)?
Have you checked the "policy" for each *tables table (it may be
set to DROP packets that match no rule)?
Have you checked if this may be dropped by a table other than
FORWARD (use *tables-save to see the full contents of all the
tables of type *tables)?
Have you checked the various accept/drop/antispoof settings under
/proc/sys/net ?
Have you checked that your tables do not limit their acceptance
to IP packets (the low level packets you are loosing may not be
"IP traffic" as far as the applicable table is concerned)?
Appreciate any thoughts/inputs that will help me proceed further.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.
http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain
errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded