4:34 p.m.
Hello,
at beginning of 2017 I configured OVN in my oVirt 4.1.0 setup, with the
previosulsy described notes, I think the ones here:
http://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/
At that time OVN was not directly integrated in oVirt setup.
Then I applied the updates in minor releases and coming at 4.1.9 level in
late January this year.
Now I plan to update to 4.2.3. I have doubts related to OVN setup.
Will the new 4.2.3 OVN setup conflict with my current 4.1.x setup?
WHat do I have to answer in setup related questions and prompt?
In fact now, after enabling 4.2 repo and updating the setup itself, during
the procedure (that I Canceled right now) I receive these questions:
# engine-setup
. . .
[ INFO ] Stage: Environment packages setup
[ INFO ] Stage: Programs detection
[ INFO ] Stage: Environment setup
[ INFO ] Stage: Environment customization
--== PRODUCT OPTIONS ==--
Configure ovirt-provider-ovn (Yes, No) [Yes]:
. . .
--== OVIRT ENGINE CONFIGURATION ==--
Perform full vacuum on the engine database engine@localhost?
This operation may take a while depending on this setup health
and the
configuration of the db vacuum process.
See https://www.postgresql.org/docs/9.0/static/sql-vacuum.html
(Yes, No) [No]: Yes
oVirt OVN provider user[admin@internal]: what_to_put_here
oVirt OVN provider password:
. . .
--== CONFIGURATION PREVIEW ==--
Default SAN wipe after delete : False
Firewall manager : firewalld
Update Firewall : True
. . .
Set up ovirt-provider-ovn : True
. . .
Configure VMConsole Proxy : True
Please confirm installation settings (OK, Cancel) [OK]: Cancel
Thanks for any hint.
Gianluca
4:50 p.m.
On Mon, May 21, 2018 at 3:34 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
Hello,
at beginning of 2017 I configured OVN in my oVirt 4.1.0 setup, with the
previosulsy described notes, I think the ones here:
http://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/
At that time OVN was not directly integrated in oVirt setup.
Then I applied the updates in minor releases and coming at 4.1.9 level in
late January this year.
Now I plan to update to 4.2.3. I have doubts related to OVN setup.
Will the new 4.2.3 OVN setup conflict with my current 4.1.x setup?
WHat do I have to answer in setup related questions and prompt?
BTW: the version of ovirt-ovn-provider package installed during latest
update to 4.1.9 has been
Jan 15 09:14:50 Updated: ovirt-provider-ovn-1.0.9-0.el7.centos.noarch
Today as pre-engine-setup phase it was updated to
May 21 15:18:28 Updated: ovirt-provider-ovn-1.2.10-1.el7.centos.noarch
I have seen this bugzilla in release notes of 4.2.1
https://bugzilla.redhat.com/show_bug.cgi?id=1529119
but I have not understood if it will apply to my setup and situation in
final 4.2.3.
Gianluca
5:55 p.m.
6:27 p.m.
Hi,
Adding also Marcin here.
I reproduced it as well and I can confirm that the external provider was
called 'OVN' by default at 4.1 time but now engine-setup will create by
default a new provider called 'ovirt-provider-ovn'.
Both the two providers are now configured in the engine to be reached at
https://<enginevm_ip>:9696
The engine can successfully talk with ovirt-provider-ovn while I get errors
like 'Error while listing external networks: EngineException: (Failed with
error Connection reset and code 5050)' when I try to query the old OVN
provider.
Logical networks previously attached to the old OVN provider are still
there in the engine and they are still attached to the old OVN provider.
Unfortunately I'm not able to start/restart VMs with interfaces on a
logical network defined on the OVN provider.
I manually recreated the missing networks on the new 'ovirt-provider-ovn'
provider and I reattached my VMs there and at that point I was finally able
to start again my VMs.
On Mon, May 21, 2018 at 4:55 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
>
>
Another information regarding my current environment:
From engine database it results that my OVN provider name is "OVN"
engine=# select id,name from providers;
id | name
--------------------------------------+------------------------
ceab03af-7220-4d42-8f5c-9b557f5d29af | ovirt-image-repository
84546a85-2958-4c1d-bbfe-afeb486ebda9 | OVN
(2 rows)
engine=#
why it seems that in its default config it would name it
"ovirt-provider-ovn"?
Does this mean that it will be no conflict in name? But what about the
current nortbridge and southbridge configs?
Currently my central server is the engine (that is external to the infra)
and it shows this:
[root@ovmgr1 ~]# ovn-sbctl show
Chassis "1dce5b7c-a9fc-4ddb-99b4-e2c9e0fa54c5"
hostname: "ov200.mydomain"
Encap geneve
ip: "10.4.192.32"
options: {csum="true"}
Chassis "b8872ab5-4606-4a79-b77d-9d956a18d349"
hostname: "ov301.mydomain"
Encap geneve
ip: "10.4.192.34"
options: {csum="true"}
Chassis "ddecf0da-4708-4f93-958b-6af365a5eeca"
hostname: "ov300.mydomain"
Encap geneve
ip: "10.4.192.33"
options: {csum="true"}
[root@ovmgr1 ~]#
and
[root@ovmgr1 ~]# ovn-nbctl show
switch 32367d8a-460f-4447-b35a-abe9ea5187e0 (ovn192)
port affc5570-3e5a-439c-9fdf-d75d6810e3a3
addresses: ["00:1a:4a:17:01:73 dynamic"]
port f639d541-2118-4c24-b478-b7a586eb170c
addresses: ["00:1a:4a:17:01:75 dynamic"]
switch 6110649a-db2b-4de7-8fbc-601095cfe510 (ovn192)
switch 64c4c17f-cd67-4e29-939e-2b952495159f (ovn172)
port 32c348d9-12e9-4bcf-a43f-69338c887cfc
addresses: ["00:1a:4a:17:01:72 dynamic"]
port 3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69
addresses: ["00:1a:4a:17:01:74 dynamic"]
switch 04501f6b-3977-4ba1-9ead-7096768d796d (ovn172)
port 0a2a47bc-ea0d-4f1d-8f49-ec903e519983
addresses: ["00:1a:4a:17:01:65 dynamic"]
port 8fc7bed4-7663-4903-922b-05e490c6a5a1
addresses: ["00:1a:4a:17:01:64 dynamic"]
port f2b64f89-b719-484c-ac02-2a1ac8eaacdb
addresses: ["00:1a:4a:17:01:59 dynamic"]
port f7389c88-1ea1-47c2-92fd-6beffb2e2190
addresses: ["00:1a:4a:17:01:58 dynamic"]
[root@ovmgr1 ~]#
and on my hosts currently I have something like this (eg on ov200):
[root@ov200 ~]# ovs-vsctl show
ae0a1256-7250-46a2-a1b6-8f0ae6105c20
Bridge br-int
fail_mode: secure
Port br-int
Interface br-int
type: internal
Port "ovn-ddecf0-0"
Interface "ovn-ddecf0-0"
type: geneve
options: {csum="true", key=flow,
remote_ip="10.4.192.33"}
Port "ovn-b8872a-0"
Interface "ovn-b8872a-0"
type: geneve
options: {csum="true", key=flow,
remote_ip="10.4.192.34"}
ovs_version: "2.7.3"
[root@ov200 ~]#
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
6:35 p.m.
On Tue, May 22, 2018 at 5:27 PM, Simone Tiraboschi <stirabos(a)redhat.com>
wrote:
Hi,
Adding also Marcin here.
I reproduced it as well and I can confirm that the external provider was
called 'OVN' by default at 4.1 time but now engine-setup will create by
default a new provider called 'ovirt-provider-ovn'.
Both the two providers are now configured in the engine to be reached at
https://<enginevm_ip>:9696
The engine can successfully talk with ovirt-provider-ovn while I get
errors like 'Error while listing external networks: EngineException:
(Failed with error Connection reset and code 5050)' when I try to query
the old OVN provider.
Logical networks previously attached to the old OVN provider are still
there in the engine and they are still attached to the old OVN provider.
Unfortunately I'm not able to start/restart VMs with interfaces on a
logical network defined on the OVN provider.
I manually recreated the missing networks on the new 'ovirt-provider-ovn'
provider and I reattached my VMs there and at that point I was finally able
to start again my VMs.
Another strange behavior.
I was't able to remove the old OVN provider since a few logical networks
was still attached to that.
So I removed all of them from the engine and then I manually removed the
old OVN provider and only at this point all of my old logical networks
manually reappeared in the engine as attached to the new 4.2
'ovirt-provider-ovn'.
On Mon, May 21, 2018 at 4:55 PM, Gianluca Cecchi <
gianluca.cecchi(a)gmail.com> wrote:
>
>
>>
>>
> Another information regarding my current environment:
> From engine database it results that my OVN provider name is "OVN"
>
> engine=# select id,name from providers;
> id | name
> --------------------------------------+------------------------
> ceab03af-7220-4d42-8f5c-9b557f5d29af | ovirt-image-repository
> 84546a85-2958-4c1d-bbfe-afeb486ebda9 | OVN
> (2 rows)
>
> engine=#
>
> why it seems that in its default config it would name it
> "ovirt-provider-ovn"?
> Does this mean that it will be no conflict in name? But what about the
> current nortbridge and southbridge configs?
>
> Currently my central server is the engine (that is external to the infra)
> and it shows this:
>
> [root@ovmgr1 ~]# ovn-sbctl show
> Chassis "1dce5b7c-a9fc-4ddb-99b4-e2c9e0fa54c5"
> hostname: "ov200.mydomain"
> Encap geneve
> ip: "10.4.192.32"
> options: {csum="true"}
> Chassis "b8872ab5-4606-4a79-b77d-9d956a18d349"
> hostname: "ov301.mydomain"
> Encap geneve
> ip: "10.4.192.34"
> options: {csum="true"}
> Chassis "ddecf0da-4708-4f93-958b-6af365a5eeca"
> hostname: "ov300.mydomain"
> Encap geneve
> ip: "10.4.192.33"
> options: {csum="true"}
> [root@ovmgr1 ~]#
>
> and
>
> [root@ovmgr1 ~]# ovn-nbctl show
> switch 32367d8a-460f-4447-b35a-abe9ea5187e0 (ovn192)
> port affc5570-3e5a-439c-9fdf-d75d6810e3a3
> addresses: ["00:1a:4a:17:01:73 dynamic"]
> port f639d541-2118-4c24-b478-b7a586eb170c
> addresses: ["00:1a:4a:17:01:75 dynamic"]
> switch 6110649a-db2b-4de7-8fbc-601095cfe510 (ovn192)
> switch 64c4c17f-cd67-4e29-939e-2b952495159f (ovn172)
> port 32c348d9-12e9-4bcf-a43f-69338c887cfc
> addresses: ["00:1a:4a:17:01:72 dynamic"]
> port 3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69
> addresses: ["00:1a:4a:17:01:74 dynamic"]
> switch 04501f6b-3977-4ba1-9ead-7096768d796d (ovn172)
> port 0a2a47bc-ea0d-4f1d-8f49-ec903e519983
> addresses: ["00:1a:4a:17:01:65 dynamic"]
> port 8fc7bed4-7663-4903-922b-05e490c6a5a1
> addresses: ["00:1a:4a:17:01:64 dynamic"]
> port f2b64f89-b719-484c-ac02-2a1ac8eaacdb
> addresses: ["00:1a:4a:17:01:59 dynamic"]
> port f7389c88-1ea1-47c2-92fd-6beffb2e2190
> addresses: ["00:1a:4a:17:01:58 dynamic"]
> [root@ovmgr1 ~]#
>
>
> and on my hosts currently I have something like this (eg on ov200):
>
> [root@ov200 ~]# ovs-vsctl show
> ae0a1256-7250-46a2-a1b6-8f0ae6105c20
> Bridge br-int
> fail_mode: secure
> Port br-int
> Interface br-int
> type: internal
> Port "ovn-ddecf0-0"
> Interface "ovn-ddecf0-0"
> type: geneve
> options: {csum="true", key=flow,
remote_ip="10.4.192.33"}
> Port "ovn-b8872a-0"
> Interface "ovn-b8872a-0"
> type: geneve
> options: {csum="true", key=flow,
remote_ip="10.4.192.34"}
> ovs_version: "2.7.3"
> [root@ov200 ~]#
>
>
> _______________________________________________
> Users mailing list -- users(a)ovirt.org
> To unsubscribe send an email to users-leave(a)ovirt.org
>
>
6:50 p.m.
On Tue, May 22, 2018 at 5:35 PM, Simone Tiraboschi <stirabos(a)redhat.com>
wrote:
On Tue, May 22, 2018 at 5:27 PM, Simone Tiraboschi <stirabos(a)redhat.com>
wrote:
> Hi,
> Adding also Marcin here.
> I reproduced it as well and I can confirm that the external provider was
> called 'OVN' by default at 4.1 time but now engine-setup will create by
> default a new provider called 'ovirt-provider-ovn'.
> Both the two providers are now configured in the engine to be reached at
> https://<enginevm_ip>:9696
>
> The engine can successfully talk with ovirt-provider-ovn while I get
> errors like 'Error while listing external networks: EngineException:
> (Failed with error Connection reset and code 5050)' when I try to query
> the old OVN provider.
> Logical networks previously attached to the old OVN provider are still
> there in the engine and they are still attached to the old OVN provider.
> Unfortunately I'm not able to start/restart VMs with interfaces on a
> logical network defined on the OVN provider.
> I manually recreated the missing networks on the new 'ovirt-provider-ovn'
> provider and I reattached my VMs there and at that point I was finally able
> to start again my VMs.
>
Another strange behavior.
I was't able to remove the old OVN provider since a few logical networks
was still attached to that.
So I removed all of them from the engine and then I manually removed the
old OVN provider and only at this point all of my old logical networks
manually reappeared in the engine as attached to the new 4.2
'ovirt-provider-ovn'.
Thank you very much Simone for your tests!
This is a test environment, but with about 40 VMs of a certain importance
and I would like to preserve it in 4.2
So with your tests you are confirming that the engine-setup for updating
engine completes without problems and impacts on current databases and then
the update of the hosts doesn't go into exception, correct?
I can manage to have a temporary downtime for the few VMs defined on ovn
(mainly used as intracluster network) and re-setup them on the new provider
in 4.2
Just a curiosity: does this mean that when the engine-setup should
configure the Northbound and Southbound DBs (and not... bridge... as I
wrote before ;-) it simply skips without aborting?
This was one of my major concerns...
Gianluca
10:28 a.m.
On Tue, May 22, 2018 at 5:50 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
On Tue, May 22, 2018 at 5:35 PM, Simone Tiraboschi
<stirabos(a)redhat.com>
wrote:
>
>
> On Tue, May 22, 2018 at 5:27 PM, Simone Tiraboschi <stirabos(a)redhat.com>
> wrote:
>
>> Hi,
>> Adding also Marcin here.
>> I reproduced it as well and I can confirm that the external provider was
>> called 'OVN' by default at 4.1 time but now engine-setup will create by
>> default a new provider called 'ovirt-provider-ovn'.
>> Both the two providers are now configured in the engine to be reached at
>> https://<enginevm_ip>:9696
>>
>> The engine can successfully talk with ovirt-provider-ovn while I get
>> errors like 'Error while listing external networks: EngineException:
>> (Failed with error Connection reset and code 5050)' when I try to query
>> the old OVN provider.
>> Logical networks previously attached to the old OVN provider are still
>> there in the engine and they are still attached to the old OVN provider.
>> Unfortunately I'm not able to start/restart VMs with interfaces on a
>> logical network defined on the OVN provider.
>> I manually recreated the missing networks on the new
'ovirt-provider-ovn'
>> provider and I reattached my VMs there and at that point I was finally able
>> to start again my VMs.
>>
>
>
> Another strange behavior.
> I was't able to remove the old OVN provider since a few logical networks
> was still attached to that.
> So I removed all of them from the engine and then I manually removed the
> old OVN provider and only at this point all of my old logical networks
> manually reappeared in the engine as attached to the new 4.2
> 'ovirt-provider-ovn'.
>
>
Thank you very much Simone for your tests!
This is a test environment, but with about 40 VMs of a certain importance
and I would like to preserve it in 4.2
So with your tests you are confirming that the engine-setup for updating
engine completes without problems and impacts on current databases and then
the update of the hosts doesn't go into exception, correct?
I simply had to manually restart ovn related services on the host to
reestablish correct TLS communication.
No other issue on host side.
I can manage to have a temporary downtime for the few VMs defined on
ovn
(mainly used as intracluster network) and re-setup them on the new provider
in 4.2
Just a curiosity: does this mean that when the engine-setup should
configure the Northbound and Southbound DBs (and not... bridge... as I
wrote before ;-) it simply skips without aborting?
This was one of my major concerns...
Yes, no errors from engine-setup; all the OVN related services got
reconfigured and their TLS cert got regenerated.
Gianluca
11:04 a.m.
Hi Gianluca,
The provider in version 4.1 was installed automatically, but it did not
save the fact of being installed.
Hence if you try to install it in 4.2, it will try to install itself again
(and this time it will save the info of being installed).
I'm planning to add a feature that will allow reusing an already existing
provider during engine-setup. For now you can skip the provider
installation, the existing one will be kept as it is.
Thanks,
Marcin
On Mon, May 21, 2018 at 4:55 PM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com>
wrote:
>
>
Another information regarding my current environment:
From engine database it results that my OVN provider name is "OVN"
engine=# select id,name from providers;
id | name
--------------------------------------+------------------------
ceab03af-7220-4d42-8f5c-9b557f5d29af | ovirt-image-repository
84546a85-2958-4c1d-bbfe-afeb486ebda9 | OVN
(2 rows)
engine=#
why it seems that in its default config it would name it
"ovirt-provider-ovn"?
Does this mean that it will be no conflict in name? But what about the
current nortbridge and southbridge configs?
Currently my central server is the engine (that is external to the infra)
and it shows this:
[root@ovmgr1 ~]# ovn-sbctl show
Chassis "1dce5b7c-a9fc-4ddb-99b4-e2c9e0fa54c5"
hostname: "ov200.mydomain"
Encap geneve
ip: "10.4.192.32"
options: {csum="true"}
Chassis "b8872ab5-4606-4a79-b77d-9d956a18d349"
hostname: "ov301.mydomain"
Encap geneve
ip: "10.4.192.34"
options: {csum="true"}
Chassis "ddecf0da-4708-4f93-958b-6af365a5eeca"
hostname: "ov300.mydomain"
Encap geneve
ip: "10.4.192.33"
options: {csum="true"}
[root@ovmgr1 ~]#
and
[root@ovmgr1 ~]# ovn-nbctl show
switch 32367d8a-460f-4447-b35a-abe9ea5187e0 (ovn192)
port affc5570-3e5a-439c-9fdf-d75d6810e3a3
addresses: ["00:1a:4a:17:01:73 dynamic"]
port f639d541-2118-4c24-b478-b7a586eb170c
addresses: ["00:1a:4a:17:01:75 dynamic"]
switch 6110649a-db2b-4de7-8fbc-601095cfe510 (ovn192)
switch 64c4c17f-cd67-4e29-939e-2b952495159f (ovn172)
port 32c348d9-12e9-4bcf-a43f-69338c887cfc
addresses: ["00:1a:4a:17:01:72 dynamic"]
port 3c77c2ea-de00-43f9-a5c5-9b3ffea5ec69
addresses: ["00:1a:4a:17:01:74 dynamic"]
switch 04501f6b-3977-4ba1-9ead-7096768d796d (ovn172)
port 0a2a47bc-ea0d-4f1d-8f49-ec903e519983
addresses: ["00:1a:4a:17:01:65 dynamic"]
port 8fc7bed4-7663-4903-922b-05e490c6a5a1
addresses: ["00:1a:4a:17:01:64 dynamic"]
port f2b64f89-b719-484c-ac02-2a1ac8eaacdb
addresses: ["00:1a:4a:17:01:59 dynamic"]
port f7389c88-1ea1-47c2-92fd-6beffb2e2190
addresses: ["00:1a:4a:17:01:58 dynamic"]
[root@ovmgr1 ~]#
and on my hosts currently I have something like this (eg on ov200):
[root@ov200 ~]# ovs-vsctl show
ae0a1256-7250-46a2-a1b6-8f0ae6105c20
Bridge br-int
fail_mode: secure
Port br-int
Interface br-int
type: internal
Port "ovn-ddecf0-0"
Interface "ovn-ddecf0-0"
type: geneve
options: {csum="true", key=flow,
remote_ip="10.4.192.33"}
Port "ovn-b8872a-0"
Interface "ovn-b8872a-0"
type: geneve
options: {csum="true", key=flow,
remote_ip="10.4.192.34"}
ovs_version: "2.7.3"
[root@ov200 ~]#
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
11:22 a.m.
On Wed, May 23, 2018 at 10:04 AM, Marcin Mirecki <mmirecki(a)redhat.com>
wrote:
Hi Gianluca,
The provider in version 4.1 was installed automatically, but it did not
save the fact of being installed.
Hence if you try to install it in 4.2, it will try to install itself again
(and this time it will save the info of being installed).
I'm planning to add a feature that will allow reusing an already existing
provider during engine-setup. For now you can skip the provider
installation, the existing one will be kept as it is.
Thanks,
Marcin
If the reinstall doesn't imply broken upgrade it is not a problem for me
and then delete the old ovn setup and reconfigure the few vnics involved
with OVN on the new environment.
If I choose to install the new one, the two inputs required:
oVirt OVN provider user[admin@internal]:
oVirt OVN provider password:
can be any settings or have to be related with the old setup?
So you advise to keep the old one and skip OVN for now and I can continue
to use in the mean time the OVN provider already setup in 4.1, correct?
Then in a future 4.2.x release when I will run engine-setup again I can
choose instead to install ovn provider, and it will keep anyway the already
configured one without need to resetup OVN and vNICS, correct?
In this case I will follow what you suggest.
Gianluca
11:38 a.m.
If the old setup is working, I would keep it, and manually update the
provider and openvswitch (yum update ...).
In the future 4.2 I hope the feature of re-using an existing provider will
already be there.
The setup is asking for user and password because we do not store these
values across invocations of engine-setup.
During a fresh install run we have it, as the user has to set it up, on
update runs we don't. The provider needs this in
order to authenticate users using ovirt-engine authentication.
Ovirt authentication for the provider can be disabled, but this has to be
done manually.
On Wed, May 23, 2018 at 10:22 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com
wrote:
> On Wed, May 23, 2018 at 10:04 AM, Marcin Mirecki <mmirecki(a)redhat.com>
wrote:
>
>> Hi Gianluca,
>>
>> The provider in version 4.1 was installed automatically, but it did not
>> save the fact of being installed.
>> Hence if you try to install it in 4.2, it will try to install itself
>> again (and this time it will save the info of being installed).
>>
>> I'm planning to add a feature that will allow reusing an already existing
>> provider during engine-setup. For now you can skip the provider
>> installation, the existing one will be kept as it is.
>>
>> Thanks,
>> Marcin
>>
>>
> If the reinstall doesn't imply broken upgrade it is not a problem for me
> and then delete the old ovn setup and reconfigure the few vnics involved
> with OVN on the new environment.
>
> If I choose to install the new one, the two inputs required:
>
> oVirt OVN provider user[admin@internal]:
> oVirt OVN provider password:
>
> can be any settings or have to be related with the old setup?
>
> So you advise to keep the old one and skip OVN for now and I can continue
> to use in the mean time the OVN provider already setup in 4.1, correct?
> Then in a future 4.2.x release when I will run engine-setup again I can
> choose instead to install ovn provider, and it will keep anyway the already
> configured one without need to resetup OVN and vNICS, correct?
> In this case I will follow what you suggest.
>
> Gianluca
>
>
>
2227
days inactive
2229
days old
9 comments
3 participants
participants (3)
-
Gianluca Cecchi -
Marcin Mirecki -
Simone Tiraboschi