On Tue, Oct 6, 2020 at 12:25 PM Konstantinos Betsis
wrote:
> Hi Dominic
>
> That fixed it.
>
Thanks for letting us know and your patience.
> VMs have full connectivity and I don't see any errors on the nodes ovn
> controller.
>
> Thanks for the help and quick responses, I really appreciate
Hi Dominic
That fixed it.
VMs have full connectivity and I don't see any errors on the nodes ovn
controller.
Thanks for the help and quick responses, I really appreciate it.
In summary for future reference:
If certificate errors are met need to review:
ovs-vsctl --no-wait get open .
On Tue, Oct 6, 2020 at 10:31 AM Konstantinos Betsis
wrote:
> Hi guys
>
> Sorry to disturb you but i am pretty much stuck at this point with the ovn
> southbound interface.
>
> Is there a way i can flush it and have it reconfigured from ovirt?
>
>
Can you please delete the chassis via
ovn-sbctl
Hi guys
Sorry to disturb you but i am pretty much stuck at this point with the ovn
southbound interface.
Is there a way i can flush it and have it reconfigured from ovirt?
Thank you
Best Regards
Konstantinos Betsis
On Thu, Oct 1, 2020 at 6:52 PM Konstantinos Betsis
wrote:
> Regarding the
Regarding the ovn-controller logs
2020-10-01T15:51:03.156Z|14143|main|INFO|OVNSB commit failed, force
recompute next time.
2020-10-01T15:51:03.220Z|14144|main|INFO|OVNSB commit failed, force
recompute next time.
2020-10-01T15:51:03.284Z|14145|main|INFO|OVNSB commit failed, force
recompute
Hi Dimitru
I've seen that as well.
I've deleted the dc01-node2 (ams03-hypersec02) from ovirt.
I've also issued ovs-vsctl emer-reset.
But ovn-sbctl list chassis still depicts the node twice.
The ovs-sbctl show still depicts 3 geneve tunnels from dc01-node2
How, can we fix this?
On Thu,
On 10/1/20 8:59 AM, Dumitru Ceara wrote:
> On 9/30/20 3:41 PM, Konstantinos Betsis wrote:
>> From the configuration I can see only three nodes.
>> "Encap":{
>> #dc01-node02
>>
On 9/30/20 3:41 PM, Konstantinos Betsis wrote:
> From the configuration I can see only three nodes.
> "Encap":{
> #dc01-node02
>
On Tue, Sep 15, 2020 at 6:53 PM Konstantinos Betsis
wrote:
> So a new test-net was created under DC01 and was depicted in the networks
> tab under both DC01 and DC02.
> I believe for some reason networks are duplicated in DCs, maybe for future
> use??? Don't know.
> If one tries to delete the
So a new test-net was created under DC01 and was depicted in the networks
tab under both DC01 and DC02.
I believe for some reason networks are duplicated in DCs, maybe for future
use??? Don't know.
If one tries to delete the network from the other DC it gets an error,
while if deleted from the
On Tue, Sep 15, 2020 at 6:18 PM Konstantinos Betsis
wrote:
> Hi Dominik
>
> Fixed the issue.
>
Thanks.
> I believe the /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
> needed update also.
> The package is upgraded to the latest version.
>
> Once the provider was updated with
Hi Dominik
Fixed the issue.
I believe the /etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
needed update also.
The package is upgraded to the latest version.
Once the provider was updated with the following it functioned perfectly:
Name: ovirt-provider-ovn
Description: oVirt
Can you try again with:
[OVN REMOTE]
ovn-remote=ssl:127.0.0.1:6641
[SSL]
https-enabled=false
ssl-cacert-file=/etc/pki/ovirt-engine/ca.pem
ssl-cert-file=/etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer
ssl-key-file=/etc/pki/ovirt-engine/keys/ovirt-provider-ovn.key.nopass
[OVIRT]
This is the updated one:
# This file is automatically generated by engine-setup. Please do not edit
manually
[OVN REMOTE]
ovn-remote=ssl:127.0.0.1:6641
[SSL]
https-enabled=true
ssl-cacert-file=/etc/pki/ovirt-engine/ca.pem
ssl-cert-file=/etc/pki/ovirt-engine/certs/ovirt-provider-ovn.cer
On Tue, Sep 15, 2020 at 5:34 PM Konstantinos Betsis
wrote:
> There is a file with the below entries
>
Impressive, do you know when this config file was created and if it was
manually modified?
Is this an upgrade from oVirt 4.1?
> [root@dc02-ovirt01 log]# cat
>
There is a file with the below entries
[root@dc02-ovirt01 log]# cat
/etc/ovirt-provider-ovn/conf.d/10-setup-ovirt-provider-ovn.conf
# This file is automatically generated by engine-setup. Please do not edit
manually
[OVN REMOTE]
ovn-remote=tcp:127.0.0.1:6641
[SSL]
https-enabled=false
On Tue, Sep 15, 2020 at 5:11 PM Konstantinos Betsis
wrote:
> Hi Dominik
>
> That immediately fixed the geneve tunnels between all hosts.
>
>
thanks for the feedback.
> However, the ovn provider is not broken.
> After fixing the networks we tried to move a VM to the DC01-host01 so we
> powered
Hi Dominik
That immediately fixed the geneve tunnels between all hosts.
However, the ovn provider is not broken.
After fixing the networks we tried to move a VM to the DC01-host01 so we
powered it down and simply configured it to run on dc01-node01.
While checking the logs on the ovirt engine i
On Mon, Sep 14, 2020 at 9:25 AM Konstantinos Betsis
wrote:
> Hi Dominik
>
> When these commands are used on the ovirt-engine host the output is the
> one depicted in your email.
> For your reference see also below:
>
> [root@ath01-ovirt01 certs]# ovn-nbctl get-ssl
> Private key:
Hi Dominik
When these commands are used on the ovirt-engine host the output is the one
depicted in your email.
For your reference see also below:
[root@ath01-ovirt01 certs]# ovn-nbctl get-ssl
Private key: /etc/pki/ovirt-engine/keys/ovn-ndb.key.nopass
Certificate:
Looks still like the ovn-controller on the host has problems communicating
with ovn-southbound.
Are there any hints in /var/log/openvswitch/*.log,
especially in /var/log/openvswitch/ovsdb-server-sb.log ?
Can you please check the output of
ovn-nbctl get-ssl
ovn-nbctl get-connection
ovn-sbctl
I did a restart of the ovn-controller, this is the output of the
ovn-controller.log
2020-09-11T10:54:07.566Z|1|vlog|INFO|opened log file
/var/log/openvswitch/ovn-controller.log
2020-09-11T10:54:07.568Z|2|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
connecting...
On Thu, Sep 10, 2020 at 6:26 PM Konstantinos B wrote:
> Hi all
>
> We have a small installation based on OVIRT 4.3.
> 1 Cluster is based on Centos 7 and the other on OVIRT NG Node image.
>
> The environment was stable till an upgrade took place a couple of months
> ago.
> As such we had to
23 matches
Mail list logo
