On 03/14/2012 11:26 AM, Maoke wrote:
yes but we still have other troubles with the 2.6.32-042stab044.11. :P
so we are trying to understand the problem first.
I don't suggest to move on 2.6.32 kernel. I said about
2.6.18-028stabXXX.Y. You can find a last stable 2.6.18 kernel here:
http://download.openvz.org/kernel/branches/rhel5-2.6.18/stable/
This issue may be already fixed.
- maoke
2012/3/14 Andrew Vagin <ava...@parallels.com
<mailto:ava...@parallels.com>>
2.6.18-194.3.1.el5.028stab069.6xen is a very old version. Could
you update it?
On 03/14/2012 10:28 AM, Maoke wrote:
sorry if this is more of a Xen problem.
we are running openvz in Xen PVs (kernel
2.6.18-194.3.1.el5.028stab069.6xen), and occasionally the
network of a PV, as well as the PV's hosted containers, at a
virtual interface is lost. sometimes restarting the network
can solve the problem but in most cases we have to restart the
PV. the PVs another virtual interface was working and other
PVs and the HV keeps working.
detailed observation through tcpdump at the trouble time shows:
1. the inbound traffics can be delivered correctly through
eth0 of the PV until venet0;
2. it looks the venet0 is also correctly functioned because
TCP sync may get response from container and this sync ack can
be seen at venet0;
3. but at the eth0 of PV, we only have seen the TCP sync
request towards the containers while the sync ack is missing,
thus TCP state of the container's application remains SYNC_RECV
4. if ping the PV, at the eth0, we only have seen the ICMP
echo requests but the replies are missing.
we didn't encounter the same problem when those openvz stuffs
were running over physical machine instead of xen.
does anyone have any hints or ideas? thanks a lot in advance.
- maoke
_______________________________________________
Users mailing list
Users@openvz.org <mailto:Users@openvz.org>
https://openvz.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@openvz.org
https://openvz.org/mailman/listinfo/users
