Hi,
with the latest upload of openvswitch v2.15.0+ds1-2+deb11u2 to
bullseye-security[1] a customer of mine, using a Proxmox Ceph cluster
(PVE 7.3) with openvswitch, got hit by a serious networking issue,
which matches this bug report.
It turned out that a service restart of the openvswitch-switch
I dug a little deeper now and this is what I found.
I had a deeper look at systemd service files and subsequently called
openvswitch scripts in /usr/share/openvswitch/scripts.
I don't know if its upstream or patched by DEBIAN by AFAICT it seems to me that
it is intended behaviour to keep OVS int
> Use auto...On Aug 17, 2022 18:02, topro wrote:
Ok, now I sacrificed one of my affected hosts by migrating away any guests and
putting it in a place where I got access to physical keeyboard and screen, so I
have a playground for testing. I tried any combination of auto and/or
allow-ovsbr1 I c
Use auto...On Aug 17, 2022 18:02, topro wrote:
>
>
> >> # eth0 onboard hw ethernet device
> >> allow-ovsbr1 eth0
> >> [...]
> >
> >You should not be using "allow-ovsbr1", as much as I understand
>
> glad to give it a try. just omit that line on both eth0 and ovsvlan99 made
> openvswitch not
>> # eth0 onboard hw ethernet device
>> allow-ovsbr1 eth0
>> [...]
>
>You should not be using "allow-ovsbr1", as much as I understand
glad to give it a try. just omit that line on both eth0 and ovsvlan99 made
openvswitch not come up on boot any more.
should I omit just on one of those two, or
On 8/17/22 15:04, topro wrote:
My network configuration file looks like this
auto lo
iface lo inet loopback
auto ovsbr1
iface ovsbr1 inet manual
ovs_type OVSBridge
ovs_ports eth0 ovsvlan99
# eth0 onboard hw ethernet device
allow-ovsbr1 eth0
[...]
You should not be using "allow-
Hi,
sorry for html mail (my fault), here again in plain text format...
as I am affected by exactly the described behaviour with exactly the mentioned
version of openvswitch packages, I gave the workaround proposed in message #10
a try. For me it did not fix the behavior. As my affected host is
Hi,
as I am affected by exactly the described behaviour with exactly the mentioned version of openvswitch packages, I gave the workaround proposed in message #10 a try. For me it did not fix the behavior. As my affected host is headless I cannot easily determine the state after network is left
Package: openvswitch-switch
Version: 2.15.0+ds1-2+deb11u1
Severity: normal
Dear Maintainer,
today we noticed on several hosts that the upgrade of openvswitch-switch
left the network configuration in a broken state. This doesn't happen
every time, but it is easily reproducible. We're using an OVSB
9 matches
Mail list logo
