WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Dom0 NETTX, NETRX always are 0

To: xen-users@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Dom0 NETTX, NETRX always are 0
From: 明石 れい <r-akashi@xxxxxxxxxxxxx>
Date: Fri, 15 Jan 2010 19:01:00 +0900
Delivery-date: Fri, 15 Jan 2010 02:01:47 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4B443AFE.1050603@xxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <4B4436BB.6040503@xxxxxxxxxxxxx> <7207d96f1001052316r2b3be933x6575da0fde107e8f@xxxxxxxxxxxxxx> <4B443AFE.1050603@xxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.22 (Windows/20090605)
 I've not found out the clue yet...
It seems like that the xen-3.4.1's xentop catch Dom0's NW I/O from vif0.0.
Check out the xentop source in xen3.4.1,
/usr/src/xen-3.4.1/tools/xenstat/libxenstat/src/xenstat_linux.c
you will find the code that tells me the xentop catch NW traffic from vif.
---------------------------------------------------------

  int ret = fscanf(priv->procnetdev,
                   "vif%u.%u:%llu%llu%llu%llu%*u%*u%*u%*u"
                   "%llu%llu%llu%llu%*u%*u%*u%*u\n",
                   &domid, &net.id,
                   &net.tbytes, &net.tpackets, &net.terrs,
                   &net.tdrop,
                   &net.rbytes, &net.rpackets, &net.rerrs,
                   &net.rdrop);

---------------------------------------------------------

But in my xen-3.4.1 env, Dom0's bridge name is eth0, but it does NOT
attached to vif0.0. This is what the brctl showing.
--------------------------------------------------------
[root@host_new scripts]# brctl show

  bridge name     bridge id               STP enabled     interfaces
  eth0            8000.003013e3e302       no              peth0

--------------------------------------------------------

In another host, it running on xen-3.1.0, bridge named xenbr0 was attached
to peth0 as well as vif0.0. So, I got correct NW I/O for Dom0.
---------------------------------------------------------

 [root@host_old ~]# brctl show
  bridge name     bridge id               STP enabled     interfaces
  xenbr0          8000.feffffffffff       no              peth0
                                                          vif0.0

----------------------------------------------------------

I just use the default /etc/xen/xend-config.sxp, there xen bridge was
really set to xen bridge mode, the same as it in xen-3.1.0's same config
file.
------------------------------
...
(network-script network-bridge)
...
(vif-script vif-bridge)
...
------------------------------

Here is the difference between xen3.1.0 and xen3.4.1.
-----------------------------

◎host_old(=Xen3.1.0)

##
# To bridge network traffic, like this:
#
# dom0: fake eth0 -> vif0.0 -+
#                            |
#                          bridge -> real eth0 -> the network
#                            |
# domU: fake eth0 -> vifN.0 -+
#
# use
#
# (network-script network-bridge)

◎host_new(=Xen3.4.1)

##
# To bridge network traffic, like this:
#
# dom0: ----------------- bridge -> real eth0 -> the network
#                            |
# domU: fake eth0 -> vifN.0 -+
#
# use
#
# (network-script network-bridge)

-------------------------------

What's wrong with me?
Any advice is appriciated.

>  Thank you! Fujar.
>   
>>   
>>     
>>> In Host2's xentop, I got the DomU's NETRX and DomU's CPU as well as
>>> Dom0's high load during netperf running. It means DomU accturally received
>>> the packats from Host1's Dom0.
>>>     
>>>       
>>   
>>     
>>> But packat sender Host1's CPU changed this way : 0.4%->71.6%->100.5
>>> (because it with 2 vcpus)
>>> I could not get packats sending out from Host1. The NETTX no changes
>>> anymore 0->0->0.
>>>     
>>>       
>> Is Host1 a HVM (fully virtualized) domU?
>>
>>   
>>     
> Host1 and Host2 are para-virtualized Dom0.
> The TTVM is DomU running at Host2.
> All of them running at a local network.
>
>
>   


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users