<div class="gmail_quote"><div><div>Missed the list in copy. sorry.<br></div><div class="h5"><br><br><div class="gmail_quote">On Fri, Apr 15, 2011 at 3:20 PM, Serge Hallyn <span dir="ltr"><<a href="mailto:serge.hallyn@canonical.com" target="_blank">serge.hallyn@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Quoting Mauras Olivier (<a href="mailto:oliver.mauras@gmail.com" target="_blank">oliver.mauras@gmail.com</a>):<br>
> Hello,<br>
><br>
> I'm struggling for two days now with some completely weird network<br>
> behaviours.<br>
> My host is a virtual machine hosted on an ESX farm. I planned to deploy<br>
> several containers on it to achieve various tasks.<br>
><br>
> Host is running Scientific Linux 6 with default kernel (2.6.32), and my<br>
> container is an Oracle Linux 6. I discovered that i had to change ESX<br>
> vswitch settings to allow promiscuous mode in order to make the host bridge<br>
> correctly behave, but it still gives me weird results.<br>
> Most of the time after having started the container, network inside the<br>
> container is erratic. I can ping or ssh from the host to the container, but<br>
> nothing gets out of the container or in the container from the LAN. While<br>
> the container is still running, if i issue a network restart on the host,<br>
> the container start behaving correctly and network works again as expected.<br>
> The problem is that it's not reliable at all. If i stop/restart the<br>
> container several times, it starts losing network again that i can only get<br>
> back by issuing the network restart on the host...<br>
<br>
</div>Just a thought, advised by previous libvirt troubles.<br>
<br>
Can you look at the mac addresses on the VMWare guest? Check that the<br>
eth0 on the vmware guest (i.e. container host) is always lower than<br>
that of the veths in the guests.<br>
<font color="#888888"><br>
-serge<br>
</font></blockquote></div></div></div>Hi Serge,<br><br>Thanks for your reply. This is one thing i found while searching for a solution and after verifying, everything seems ok.<br>I did decide by the way to force a high MAC for containers so now they have fe:ff:xxxxxx MACs. Is there a way to force the veth MAC on the host side? What i noted is that in any case, when i issue the network restart on the host and get back network in the container, there's not a change on MACs. veth stays with the same MAC as long as i don't restart the container.<br>
<br>Here's an example:<br><br>[root@host 16:08:39 ~]# ip addr<br>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN <br> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br> inet <a href="http://127.0.0.1/8" target="_blank">127.0.0.1/8</a> scope host lo<br>
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000<br> link/ether 00:50:56:ae:00:41 brd ff:ff:ff:ff:ff:ff<br>6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN <br>
link/ether 00:50:56:ae:00:41 brd ff:ff:ff:ff:ff:ff<br> inet <a href="http://192.168.1.1/24" target="_blank">192.168.1.1/24</a> brd 192.168.1.255 scope global br0<br>17: veth56nN7a: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000<br>
link/ether a2:8a:f2:ec:f1:1b brd ff:ff:ff:ff:ff:ff<br><br>[root@host 16:08:42 ~]# ssh guest <br>
root@guest 's password: <br><br>[root@guest ~]# curl -I <a href="http://www.coredumb.net" target="_blank">www.coredumb.net</a><br>curl: (7) couldn't connect to host<br><br>[root@guest ~]# logout<br>Connection to guest closed.<br>
<br>[root@host 16:11:22 ~]# /etc/init.d/network restart <br>Shutting down interface br0: [ OK ]<br>
Shutting down interface eth0: [ OK ]<br>Shutting down loopback interface: [ OK ]<br>Bringing up loopback interface: [ OK ]<br>Bringing up interface eth0: [ OK ]<br>
Bringing up interface br0: [ OK ]<br><br>[root@host 16:11:58 ~]# ip addr <br>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN <br> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br> inet <a href="http://127.0.0.1/8" target="_blank">127.0.0.1/8</a> scope host lo<br>
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000<br>
link/ether 00:50:56:ae:00:41 brd ff:ff:ff:ff:ff:ff<br>6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN <br> link/ether 00:50:56:ae:00:41 brd ff:ff:ff:ff:ff:ff<br> inet <a href="http://192.168.1.1/24" target="_blank">192.168.1.1/24</a> brd 192.168.1.255 scope global br0<br>
17: veth56nN7a: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000<br> link/ether a2:8a:f2:ec:f1:1b brd ff:ff:ff:ff:ff:ff<br><br>[root@host 16:12:01 ~]# ssh guest <br>
root@guest's password: <br><br>[root@guest ~]# curl -I <a href="http://www.coredumb.net" target="_blank">www.coredumb.net</a> <br>
HTTP/1.1 200 OK<br>Date: Fri, 15 Apr 2011 14:13:04 GMT<br>Server: Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/0.9.8m DAV/2 PHP/5.2.10 SVN/1.6.4<br>X-Powered-By: PHP/5.2.10<br>Expires: Tue, 01 Jan 2002 00:00:00 GMT<br>Cache-Control: no-store, no-cache, must-revalidate<br>
Pragma: no-cache<br>Content-Type: text/html; charset=ISO-8859-1;<br>Proxy-Connection: Keep-Alive<br>Connection: Keep-Alive<br>Set-Cookie: PHPSESSID=giplm9rrr0nmb1fo03f6u39435; path=/<br><br><br>As you see in this example, before issuing the network restart, my veth MAC was already higher than the eth0 MAC but the guest hadn't a working network connection.<br>
After restarting network on the host while the guest is still running, as you can see my MACs haven't changed a bit but now the network inside the guest is working correctly.<br><br>Hope this helps to better understand the problem.<br>
<br>Cheers,<br><font color="#888888">Olivier<br><br>
</font></div><br>