Hello.
I need your help, DomU xen network diconnects randomly, how do you
monitoring this?
When I connect to vnc server in the hosts, DomU is running, then I open the
DomU, after that guest network responds.
DomU Debian 6.03 over Centos 5.7 and Xen 3.03.
My network configuration:
eth0 Link encap:Ethernet HWaddr 68:B5:99:78:AA:6D
inet addr:192.168.5.230 Bcast:192.168.5.255 Mask:255.255.255.0
inet6 addr: fe80::6ab5:99ff:fe78:ad6c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4237972 errors:0 dropped:0 overruns:0 frame:0
TX packets:2663665 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:547319641 (521.9 MiB) TX bytes:220520225 (210.3 MiB)
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:1090692 errors:0 dropped:0 overruns:0 frame:0
TX packets:1090692 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:89713135 (85.5 MiB) TX bytes:89713135 (85.5 MiB)
peth0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:14557550 errors:102 dropped:0 overruns:0 frame:0
TX packets:18532553 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2011028398 (1.8 GiB) TX bytes:20743371955 (19.3 GiB)
tap0 Link encap:Ethernet HWaddr FE:DC:03:FA:0A:FD
inet6 addr: fe80::fcdc:3ff:fefa:afd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:340892 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:32530658 (31.0 MiB)
tap1 Link encap:Ethernet HWaddr FE:93:1B:49:51:2B
inet6 addr: fe80::fc93:1bff:fe49:512b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:340872 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:32529356 (31.0 MiB)
tap2 Link encap:Ethernet HWaddr FE:E1:0F:73:C5:69
inet6 addr: fe80::fce1:fff:fe73:c569/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:340842 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:32527197 (31.0 MiB)
tap3 Link encap:Ethernet HWaddr FE:CF:0C:41:CF:29
inet6 addr: fe80::fccf:cff:fe41:cf29/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:340839 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:32526987 (31.0 MiB)
vif0.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:2663690 errors:0 dropped:0 overruns:0 frame:0
TX packets:4237985 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:220525759 (210.3 MiB) TX bytes:547320421 (521.9 MiB)
vif1.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:402315 errors:0 dropped:0 overruns:0 frame:0
TX packets:902391 errors:0 dropped:28279 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:889703904 (848.4 MiB) TX bytes:114468432 (109.1 MiB)
vif2.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:75264 errors:0 dropped:0 overruns:0 frame:0
TX packets:397841 errors:0 dropped:28153 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:196606268 (187.4 MiB) TX bytes:76569944 (73.0 MiB)
vif3.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:6774649 errors:0 dropped:0 overruns:0 frame:0
TX packets:9914065 errors:0 dropped:24570 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:19334745479 (18.0 GiB) TX bytes:1359548138 (1.2 GiB)
vif4.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:2416 errors:0 dropped:0 overruns:0 frame:0
TX packets:341880 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:225475 (220.1 KiB) TX bytes:32702082 (31.1 MiB)
virbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
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:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:6748 (6.5 KiB)
xenbr0 Link encap:Ethernet HWaddr FE:93:1B:49:51:2B
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:324811 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:26883663 (25.6 MiB) TX bytes:0 (0.0 b)
[root@virtual2 pvasquez]#
Julio
Date: Sun, 29 Jul 2012 12:01:58 +0200
From: Mark van Dijk <lists+xen@internecto.net>
To: xen-users@lists.xen.org
Subject: [Xen-users] Xen networking experiment (with custom scripts
and OpenVSwitch)
Message-ID: <20120729120158.73ab4f91@internecto.net>
Content-Type: text/plain; charset=US-ASCII
Hello everyone,
Recently I have been testing my customized Xen 4.2 networking setup. It
works pretty good and I would like to share it with anyone who is
interested.
The relevant files can be found here:
https://github.com/slacks42/xenscripts
Benefit: configure the Xen related networking devices with one
understandable bash script.
Please note that this is all still work in progress. For example, some
logging entries should be deleted or modified, and some routines could
be cleaned up. Still, I think it''s nice enough to share.
Description of the files:
xen.conf is basically a copy of /etc/xen/hotplugpath.sh and should be
put in /etc/xen/.
udev/xen-backend.rules is a modified version of the file supplied by
Xen. Line 6-9 take care of creation and deletion of
networking interfaces. As you can see, upon creation/deletion of a
network interface, the file /etc/xen/scripts/xennet is called. This
file can be found on github in the scripts directory.
Xennet is a replacement of vif-bridge. In the old scenario, udev
calls vif-setup, vif-setup calls vif-bridge, vif-bridge calls
vif-common and numerous other scripts. With xennet, I wanted to have one
script to take care of the networking. So xennet requires no other files
from /etc/xen/scripts.
As you can see xennet uses bash. It is not POSIX compliant but works
fine with bash. This takes us to the second millennium ;-)
Here is a rundown of xennet:
Line 4 takes care of all error output from the script. This is a handy
way to debug, especially if you alter line 1 to ''#!/bin/bash
-x'' so
that you can see exactly what the script does.
Then on line 8, the $unique variable is set to a random 6 character
wide string, a ''cookie'' of sorts, this is used as a log prefix
so that
you can see which particular instance of the script does what.
Then a couple of functions are initialized. The checklog() and
logmsg() functions take care of logging at the requested loglevel (set
in xen.conf). This is different from line 4; logmsg is a function that
logs to the console, syslog, or a file (xen.conf).
The sigerr(), fatal(), success(), xenstore_read_default(),
findCommand() and evalVariables() functions are modified versions of the
same functions in Xen''s xen-script-common.sh file.
I added line 191-198 for debugging, rather than calling the actual
commands they fake their execution and only add a log entry. That''s why
they are commented out.
The actual routine starts at line 200. Line 201 sets $command to
online/offline/add/remove depending on how the script was called from
xen-backend.rules. evalVariables (line 202) searches for arguments with
an ''='', like ''foo=bar'', and sets those
variables accordingly (like
$foo == ''bar''). This is a nice trick I found in
xen-script-common.sh.
On to line 220-292. This searches for the vifname and bridge name. If
$command is ''offline'' or ''remove'' then I
found that it does not know
the vifname so it needs a way to find that. In all cases $vifname is
set to the requested vifname. Openvswitch does not require a bridge
name if you remove a device. So $bridge is not required with
''offline''
or ''remove''.
Line 297-337 adds or removes the vif from the switch. With openvswitch
this can be a "fake bridge", i.e. a VLAN tagged bridge, or an
unmanaged
switch. One could easily replace the ovs-vswitch commands with brctl
commands if desired, I *think*.
Xen 4.2, when used with xl, does not setup or change your networking
(as we saw with older Xen and network-bridge). So you need to do that
yourself which is a much better idea imho anyway. In my case, my init
scripts start up openvswitch when the system boots and my custom
networking script creates the relevant switches and interfaces and
configures those.
Finally -- openvswitch can have a lot of messy output that can fill up
your syslog files. syslog-ng.conf is something I use to limit
openvswitch''s output to /var/log/openvswitch.log.
Note that I seem to use the word ''switch'' and
''bridge'' while I am
talking about the same thing. Don''t let this confuse you.
Comments are appreciated!
Mark
------------------------------
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
End of Xen-users Digest, Vol 89, Issue 45
*****************************************
Hi,
as there''s Marks "networking experiments" mail attached to
your''s, I''m
quite not sure if you''re
using the legacy (as of your CentOS 5/Xen3 setup) way, or maybe trying
the experimental one.
I guess, the attached mail is unrelated, otherwise I''ld have probably
noticed openvswitch.
Install ethtool inside your domU and try
ethtool -K eth0 tx off # assuming eth0 is your domU''s interface to
xenbr0
if that helps, you could add that line in your domU''s interfaces (below
the respective iface statement):
post-up ethtool -K eth0 tx off
cheers,
Stephan
Am Montag, den 30.07.2012, 10:50 -0500 schrieb Julio Solórzano:
> Hello.
> I need your help, DomU xen network diconnects randomly, how do you
> monitoring this?
> When I connect to vnc server in the hosts, DomU is running, then I open the
> DomU, after that guest network responds.
> DomU Debian 6.03 over Centos 5.7 and Xen 3.03.
> My network configuration:
> eth0 Link encap:Ethernet HWaddr 68:B5:99:78:AA:6D
> inet addr:192.168.5.230 Bcast:192.168.5.255 Mask:255.255.255.0
> inet6 addr: fe80::6ab5:99ff:fe78:ad6c/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:4237972 errors:0 dropped:0 overruns:0 frame:0
> TX packets:2663665 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:547319641 (521.9 MiB) TX bytes:220520225 (210.3 MiB)
>
> 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:1090692 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1090692 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:89713135 (85.5 MiB) TX bytes:89713135 (85.5 MiB)
>
> peth0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
> inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
> UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
> RX packets:14557550 errors:102 dropped:0 overruns:0 frame:0
> TX packets:18532553 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:2011028398 (1.8 GiB) TX bytes:20743371955 (19.3 GiB)
>
> tap0 Link encap:Ethernet HWaddr FE:DC:03:FA:0A:FD
> inet6 addr: fe80::fcdc:3ff:fefa:afd/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:340892 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:500
> RX bytes:0 (0.0 b) TX bytes:32530658 (31.0 MiB)
>
> tap1 Link encap:Ethernet HWaddr FE:93:1B:49:51:2B
> inet6 addr: fe80::fc93:1bff:fe49:512b/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:340872 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:500
> RX bytes:0 (0.0 b) TX bytes:32529356 (31.0 MiB)
>
> tap2 Link encap:Ethernet HWaddr FE:E1:0F:73:C5:69
> inet6 addr: fe80::fce1:fff:fe73:c569/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:340842 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:500
> RX bytes:0 (0.0 b) TX bytes:32527197 (31.0 MiB)
>
> tap3 Link encap:Ethernet HWaddr FE:CF:0C:41:CF:29
> inet6 addr: fe80::fccf:cff:fe41:cf29/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:340839 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:500
> RX bytes:0 (0.0 b) TX bytes:32526987 (31.0 MiB)
>
> vif0.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
> inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
> UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
> RX packets:2663690 errors:0 dropped:0 overruns:0 frame:0
> TX packets:4237985 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:220525759 (210.3 MiB) TX bytes:547320421 (521.9 MiB)
>
> vif1.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
> inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
> UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
> RX packets:402315 errors:0 dropped:0 overruns:0 frame:0
> TX packets:902391 errors:0 dropped:28279 overruns:0 carrier:0
> collisions:0 txqueuelen:500
> RX bytes:889703904 (848.4 MiB) TX bytes:114468432 (109.1 MiB)
>
> vif2.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
> inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
> UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
> RX packets:75264 errors:0 dropped:0 overruns:0 frame:0
> TX packets:397841 errors:0 dropped:28153 overruns:0 carrier:0
> collisions:0 txqueuelen:500
> RX bytes:196606268 (187.4 MiB) TX bytes:76569944 (73.0 MiB)
>
> vif3.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
> inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
> UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
> RX packets:6774649 errors:0 dropped:0 overruns:0 frame:0
> TX packets:9914065 errors:0 dropped:24570 overruns:0 carrier:0
> collisions:0 txqueuelen:500
> RX bytes:19334745479 (18.0 GiB) TX bytes:1359548138 (1.2 GiB)
>
> vif4.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
> inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
> UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
> RX packets:2416 errors:0 dropped:0 overruns:0 frame:0
> TX packets:341880 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:500
> RX bytes:225475 (220.1 KiB) TX bytes:32702082 (31.1 MiB)
>
> virbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
> 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:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:0 (0.0 b) TX bytes:6748 (6.5 KiB)
>
> xenbr0 Link encap:Ethernet HWaddr FE:93:1B:49:51:2B
> UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
> RX packets:324811 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:26883663 (25.6 MiB) TX bytes:0 (0.0 b)
>
> [root@virtual2 pvasquez]#
>
> Julio
>
>
> Date: Sun, 29 Jul 2012 12:01:58 +0200
> From: Mark van Dijk <lists+xen@internecto.net>
> To: xen-users@lists.xen.org
> Subject: [Xen-users] Xen networking experiment (with custom scripts
> and OpenVSwitch)
> Message-ID: <20120729120158.73ab4f91@internecto.net>
> Content-Type: text/plain; charset=US-ASCII
>
> Hello everyone,
>
> Recently I have been testing my customized Xen 4.2 networking setup. It
> works pretty good and I would like to share it with anyone who is
> interested.
>
> The relevant files can be found here:
> https://github.com/slacks42/xenscripts
>
> Benefit: configure the Xen related networking devices with one
> understandable bash script.
>
> Please note that this is all still work in progress. For example, some
> logging entries should be deleted or modified, and some routines could
> be cleaned up. Still, I think it''s nice enough to share.
>
> Description of the files:
>
> xen.conf is basically a copy of /etc/xen/hotplugpath.sh and should be
> put in /etc/xen/.
>
> udev/xen-backend.rules is a modified version of the file supplied by
> Xen. Line 6-9 take care of creation and deletion of
> networking interfaces. As you can see, upon creation/deletion of a
> network interface, the file /etc/xen/scripts/xennet is called. This
> file can be found on github in the scripts directory.
>
> Xennet is a replacement of vif-bridge. In the old scenario, udev
> calls vif-setup, vif-setup calls vif-bridge, vif-bridge calls
> vif-common and numerous other scripts. With xennet, I wanted to have one
> script to take care of the networking. So xennet requires no other files
> from /etc/xen/scripts.
>
> As you can see xennet uses bash. It is not POSIX compliant but works
> fine with bash. This takes us to the second millennium ;-)
>
> Here is a rundown of xennet:
>
> Line 4 takes care of all error output from the script. This is a handy
> way to debug, especially if you alter line 1 to ''#!/bin/bash
-x'' so
> that you can see exactly what the script does.
>
> Then on line 8, the $unique variable is set to a random 6 character
> wide string, a ''cookie'' of sorts, this is used as a log
prefix so that
> you can see which particular instance of the script does what.
>
> Then a couple of functions are initialized. The checklog() and
> logmsg() functions take care of logging at the requested loglevel (set
> in xen.conf). This is different from line 4; logmsg is a function that
> logs to the console, syslog, or a file (xen.conf).
>
> The sigerr(), fatal(), success(), xenstore_read_default(),
> findCommand() and evalVariables() functions are modified versions of the
> same functions in Xen''s xen-script-common.sh file.
>
> I added line 191-198 for debugging, rather than calling the actual
> commands they fake their execution and only add a log entry.
That''s why
> they are commented out.
>
> The actual routine starts at line 200. Line 201 sets $command to
> online/offline/add/remove depending on how the script was called from
> xen-backend.rules. evalVariables (line 202) searches for arguments with
> an ''='', like ''foo=bar'', and sets those
variables accordingly (like
> $foo == ''bar''). This is a nice trick I found in
xen-script-common.sh.
>
> On to line 220-292. This searches for the vifname and bridge name. If
> $command is ''offline'' or ''remove'' then
I found that it does not know
> the vifname so it needs a way to find that. In all cases $vifname is
> set to the requested vifname. Openvswitch does not require a bridge
> name if you remove a device. So $bridge is not required with
''offline''
> or ''remove''.
>
> Line 297-337 adds or removes the vif from the switch. With openvswitch
> this can be a "fake bridge", i.e. a VLAN tagged bridge, or an
unmanaged
> switch. One could easily replace the ovs-vswitch commands with brctl
> commands if desired, I *think*.
>
> Xen 4.2, when used with xl, does not setup or change your networking
> (as we saw with older Xen and network-bridge). So you need to do that
> yourself which is a much better idea imho anyway. In my case, my init
> scripts start up openvswitch when the system boots and my custom
> networking script creates the relevant switches and interfaces and
> configures those.
>
> Finally -- openvswitch can have a lot of messy output that can fill up
> your syslog files. syslog-ng.conf is something I use to limit
> openvswitch''s output to /var/log/openvswitch.log.
>
> Note that I seem to use the word ''switch'' and
''bridge'' while I am
> talking about the same thing. Don''t let this confuse you.
>
> Comments are appreciated!
>
> Mark
>
>
>
> ------------------------------
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
>
>
> End of Xen-users Digest, Vol 89, Issue 45
> *****************************************
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xen.org
> http://lists.xen.org/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
Hi,
Thanks, Ill try; my host is a CentOS 5/Xen3 pre installed.
Julio.
_____
De: Stephan Seitz [mailto:s.seitz@netzhaut.de]
Enviado el: Lunes, 30 de Julio de 2012 12:52 p.m.
Para: Julio Solórzano
CC: xen-users@lists.xen.org
Asunto: Re: [Xen-users] Xen networking disconnect
Hi,
as there''s Marks "networking experiments" mail attached to
your''s, I''m quite
not sure if you''re
using the legacy (as of your CentOS 5/Xen3 setup) way, or maybe trying the
experimental one.
I guess, the attached mail is unrelated, otherwise I''ld have probably
noticed openvswitch.
Install ethtool inside your domU and try
ethtool -K eth0 tx off # assuming eth0 is your domU''s interface to
xenbr0
if that helps, you could add that line in your domU''s interfaces (below
the
respective iface statement):
post-up ethtool -K eth0 tx off
cheers,
Stephan
Am Montag, den 30.07.2012, 10:50 -0500 schrieb Julio Solórzano:
Hello.
I need your help, DomU xen network diconnects randomly, how do you
monitoring this?
When I connect to vnc server in the hosts, DomU is running, then I open the
DomU, after that guest network responds.
DomU Debian 6.03 over Centos 5.7 and Xen 3.03.
My network configuration:
eth0 Link encap:Ethernet HWaddr 68:B5:99:78:AA:6D
inet addr:192.168.5.230 Bcast:192.168.5.255 Mask:255.255.255.0
inet6 addr: fe80::6ab5:99ff:fe78:ad6c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:4237972 errors:0 dropped:0 overruns:0 frame:0
TX packets:2663665 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:547319641 (521.9 MiB) TX bytes:220520225 (210.3 MiB)
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:1090692 errors:0 dropped:0 overruns:0 frame:0
TX packets:1090692 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:89713135 (85.5 MiB) TX bytes:89713135 (85.5 MiB)
peth0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:14557550 errors:102 dropped:0 overruns:0 frame:0
TX packets:18532553 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2011028398 (1.8 GiB) TX bytes:20743371955 (19.3 GiB)
tap0 Link encap:Ethernet HWaddr FE:DC:03:FA:0A:FD
inet6 addr: fe80::fcdc:3ff:fefa:afd/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:340892 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:32530658 (31.0 MiB)
tap1 Link encap:Ethernet HWaddr FE:93:1B:49:51:2B
inet6 addr: fe80::fc93:1bff:fe49:512b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:340872 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:32529356 (31.0 MiB)
tap2 Link encap:Ethernet HWaddr FE:E1:0F:73:C5:69
inet6 addr: fe80::fce1:fff:fe73:c569/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:340842 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:32527197 (31.0 MiB)
tap3 Link encap:Ethernet HWaddr FE:CF:0C:41:CF:29
inet6 addr: fe80::fccf:cff:fe41:cf29/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:340839 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:0 (0.0 b) TX bytes:32526987 (31.0 MiB)
vif0.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:2663690 errors:0 dropped:0 overruns:0 frame:0
TX packets:4237985 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:220525759 (210.3 MiB) TX bytes:547320421 (521.9 MiB)
vif1.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:402315 errors:0 dropped:0 overruns:0 frame:0
TX packets:902391 errors:0 dropped:28279 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:889703904 (848.4 MiB) TX bytes:114468432 (109.1 MiB)
vif2.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:75264 errors:0 dropped:0 overruns:0 frame:0
TX packets:397841 errors:0 dropped:28153 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:196606268 (187.4 MiB) TX bytes:76569944 (73.0 MiB)
vif3.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:6774649 errors:0 dropped:0 overruns:0 frame:0
TX packets:9914065 errors:0 dropped:24570 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:19334745479 (18.0 GiB) TX bytes:1359548138 (1.2 GiB)
vif4.0 Link encap:Ethernet HWaddr FE:FF:FF:FF:FF:FF
inet6 addr: fe80::fcff:ffff:feff:ffff/64 Scope:Link
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:2416 errors:0 dropped:0 overruns:0 frame:0
TX packets:341880 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:225475 (220.1 KiB) TX bytes:32702082 (31.1 MiB)
virbr0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
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:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:27 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:6748 (6.5 KiB)
xenbr0 Link encap:Ethernet HWaddr FE:93:1B:49:51:2B
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:324811 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:26883663 (25.6 MiB) TX bytes:0 (0.0 b)
[root@virtual2 pvasquez]#
Julio
Date: Sun, 29 Jul 2012 12:01:58 +0200
From: Mark van Dijk <lists+xen@internecto.net>
To: xen-users@lists.xen.org
Subject: [Xen-users] Xen networking experiment (with custom scripts
and OpenVSwitch)
Message-ID: <20120729120158.73ab4f91@internecto.net>
Content-Type: text/plain; charset=US-ASCII
Hello everyone,
Recently I have been testing my customized Xen 4.2 networking setup. It
works pretty good and I would like to share it with anyone who is
interested.
The relevant files can be found here:
https://github.com/slacks42/xenscripts
Benefit: configure the Xen related networking devices with one
understandable bash script.
Please note that this is all still work in progress. For example, some
logging entries should be deleted or modified, and some routines could
be cleaned up. Still, I think it''s nice enough to share.
Description of the files:
xen.conf is basically a copy of /etc/xen/hotplugpath.sh and should be
put in /etc/xen/.
udev/xen-backend.rules is a modified version of the file supplied by
Xen. Line 6-9 take care of creation and deletion of
networking interfaces. As you can see, upon creation/deletion of a
network interface, the file /etc/xen/scripts/xennet is called. This
file can be found on github in the scripts directory.
Xennet is a replacement of vif-bridge. In the old scenario, udev
calls vif-setup, vif-setup calls vif-bridge, vif-bridge calls
vif-common and numerous other scripts. With xennet, I wanted to have one
script to take care of the networking. So xennet requires no other files
from /etc/xen/scripts.
As you can see xennet uses bash. It is not POSIX compliant but works
fine with bash. This takes us to the second millennium ;-)
Here is a rundown of xennet:
Line 4 takes care of all error output from the script. This is a handy
way to debug, especially if you alter line 1 to ''#!/bin/bash
-x'' so
that you can see exactly what the script does.
Then on line 8, the $unique variable is set to a random 6 character
wide string, a ''cookie'' of sorts, this is used as a log prefix
so that
you can see which particular instance of the script does what.
Then a couple of functions are initialized. The checklog() and
logmsg() functions take care of logging at the requested loglevel (set
in xen.conf). This is different from line 4; logmsg is a function that
logs to the console, syslog, or a file (xen.conf).
The sigerr(), fatal(), success(), xenstore_read_default(),
findCommand() and evalVariables() functions are modified versions of the
same functions in Xen''s xen-script-common.sh file.
I added line 191-198 for debugging, rather than calling the actual
commands they fake their execution and only add a log entry. That''s why
they are commented out.
The actual routine starts at line 200. Line 201 sets $command to
online/offline/add/remove depending on how the script was called from
xen-backend.rules. evalVariables (line 202) searches for arguments with
an ''='', like ''foo=bar'', and sets those
variables accordingly (like
$foo == ''bar''). This is a nice trick I found in
xen-script-common.sh.
On to line 220-292. This searches for the vifname and bridge name. If
$command is ''offline'' or ''remove'' then I
found that it does not know
the vifname so it needs a way to find that. In all cases $vifname is
set to the requested vifname. Openvswitch does not require a bridge
name if you remove a device. So $bridge is not required with
''offline''
or ''remove''.
Line 297-337 adds or removes the vif from the switch. With openvswitch
this can be a "fake bridge", i.e. a VLAN tagged bridge, or an
unmanaged
switch. One could easily replace the ovs-vswitch commands with brctl
commands if desired, I *think*.
Xen 4.2, when used with xl, does not setup or change your networking
(as we saw with older Xen and network-bridge). So you need to do that
yourself which is a much better idea imho anyway. In my case, my init
scripts start up openvswitch when the system boots and my custom
networking script creates the relevant switches and interfaces and
configures those.
Finally -- openvswitch can have a lot of messy output that can fill up
your syslog files. syslog-ng.conf is something I use to limit
openvswitch''s output to /var/log/openvswitch.log.
Note that I seem to use the word ''switch'' and
''bridge'' while I am
talking about the same thing. Don''t let this confuse you.
Comments are appreciated!
Mark
------------------------------
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
End of Xen-users Digest, Vol 89, Issue 45
*****************************************
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xen.org
http://lists.xen.org/xen-users
> as there''s Marks "networking experiments" mail attached to your''s, I''m > quite not sure if you''re using the legacy (as of your CentOS 5/Xen3 > setup) way, or maybe trying the experimental one. I guess, the > attached mail is unrelated, otherwise I''ld have probably noticed > openvswitch.I think he''s not using it. But I have to add that I''m not even sure whether my method works on Xen older than version 4.. -- Stay in touch, Mark van Dijk. ,-------------------------------- ---------------------------'' Tue Jul 31 02:07 UTC 2012 Today is Boomtime, the 66th day of Confusion in the YOLD 3178