[Users] Solved: network manager is the culprit (was: OVZ 7 network issues...)

jjs - mainphrame jjs at mainphrame.com
Tue Jan 3 23:47:02 MSK 2023


Update -

It appears to be fairly straightforward to enable forwarding with firewalld
in RHEL 9, so hopefully a plain vanilla openvz 9 will be able to do
everything we need to do.

Looking forward to OVZ 9, will be happy to beta test

Jake



On Sat, Dec 31, 2022 at 2:31 PM jjs - mainphrame <jjs at mainphrame.com> wrote:

> Curious side note -
>
> Replacing firewalld with ufw allows traffic to be forwarded by the
> container. I gather that firewalld was designed for a workstation or a
> laptop, not a multi-homed server. That, and the version of firewalld on
> RHEL 7 is rather old.
>
> In any case, all of the "direct" firewalld rules that should have done the
> trick haven't done so.
>
> I'm curious to see if the newer version of firewalld that comes with RHEL
> 9 will be any more cooperative on this front.
>
> Jake
>
> On Mon, Dec 26, 2022 at 12:36 PM jjs - mainphrame <jjs at mainphrame.com>
> wrote:
>
>> Greetings -
>>
>> It's 2022, I have a new set of openvz servers, and once again, disabling
>> NetworkManager was the key to solving a nagging, intermittent network
>> problem.
>>
>> I recently added interfaces to the openvz servers to connect them to
>> other networks, and while everything seemed to work initially, the bridges
>> kept going down mysteriously.
>>
>> I tried removing and rebuilding the bridges, the networks, the virtual
>> interfaces, seeing the bridge come up, and then syslog showing
>> NetworkManager was taking the bridge down for vague and inscrutable
>> reasons, I disabled NetworkManager, and voila. No more bridge problems.
>>
>> It seems to me that NetworkManager doesn't add any value for a server,
>> only additional failure modes. Perhaps it's a solution in search of a
>> problem, as they say?
>>
>> Jake
>>
>> On Thu, Dec 31, 2015 at 1:15 PM jjs - mainphrame <jjs at mainphrame.com>
>> wrote:
>>
>>> Greetings -
>>>
>>> It's been 2 weeks of flawless network connectivity to all containers
>>> after completely removing network manager, even after attempts to induce
>>> the sort of failure that were seen when network manager was running,.
>>>
>>> At this point, it's clear that network manager was the problem, and the
>>> old saw is confirmed: "simple is safe".
>>>
>>> Happy new year to all who were following this question.
>>>
>>> Joe
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Dec 14, 2015 at 9:51 AM, Konstantin Bukharov <bkb at virtuozzo.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> From symptoms, it looks like ARP cache expiration issue.
>>>>
>>>> Please check ARP cache settings on your network equipment.
>>>>
>>>>
>>>>
>>>> We haven’t seen such massive reports.
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>>
>>>>
>>>> *From:* users-bounces at openvz.org [mailto:users-bounces at openvz.org] *On
>>>> Behalf Of *jjs - mainphrame
>>>> *Sent:* Saturday, December 12, 2015 6:18
>>>> *To:* users at openvz.org
>>>> *Subject:* [Users] OVZ 7 network issues (vz host stops answering arp
>>>> requests)
>>>>
>>>>
>>>>
>>>> Greetings,
>>>>
>>>>
>>>>
>>>> I've been running some servers in OVZ 7 containers for some months now,
>>>> and I'm happy with reliability and performance, with the exception of an
>>>> occasional loss of ct network connectivity.
>>>>
>>>> From time to time, I'll get a xymon alert that all containers are
>>>> unreachable. The cts are all using host routing. What I see, when I examine
>>>> any affected ct, is this:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> The container no longer responds to ping, even from the local lan.
>>>>
>>>> The vz host and container can connect to each other
>>>>
>>>> The container can not reach anything beyond the host.
>>>>
>>>>
>>>>
>>>> When I enter the container and ping another box, the pings are
>>>> received, but the box can not return the pings as the arp request goes
>>>> unanswered. For some reason the vz host forgets about the cts, and it's
>>>> always all of them. This is 2 Centos 7 boxes, running OVZ 7 beta and OVZ 7
>>>> factory
>>>>
>>>>
>>>>
>>>> Doing a vzctl restart on each affected ct restores connectivity. Has
>>>> anyone else seen this issue?
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at openvz.org
>>>> https://lists.openvz.org/mailman/listinfo/users
>>>>
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20230103/52903c64/attachment.html>


More information about the Users mailing list